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PREFAPA 


Dintre performantele mui procesor, viteza de procesare apare ca 
cea mai uzuala metrica si care, într-un limbaj mai mult comercial decât 
profesional, se exprima prin Milioane-de-Instructiuni-Pe-Secunda (MIPS). 
Valoarea acestui numar de instructiuni procesate pe secunda este 
determinata de doua caracteristici: frecventa perioadei de ceas si numarul 
de Cicli-Per-executia-Instructiunii (CPI). lata cum, cel putin într-o 
abordare teoretica, în stadiul de proiectare al unui microprocesor poate fi 
satisfacuta nevoia de viteze tot mai mari prin: cresterea frecventei de ceas si 
micsorarea numarului de cicli per instructiune. Prima caracteristica are o 
determinare exclusiv tehnologica iar cea de a doua este puternic influentata 
de arhitectura si organizarea microprocesorului. 

Tehnologia de integrare, acum la jonctiunea dintre milenii, ofera 
performante care depasesc previziunile facute cu numai câtiva ani înainte. 
Astfel, frecventele de ceas la procesoarele comerciale care vor veni într-un 
an-doi se apropie de I GHz, densitati de integrare de un miliard de 
componente pe chip la structurile regulate (realizabile si la structurile 
neordonate — microprocesoare — în urmatorii ani) dar si costul unei astfel 
de capacitati tehnologice la o caracteristica de 0,18 um este tot de ordinul a 
zece la puterea a noua $. 

În privinta numarului de cicli per instructiune, prin exploatarea la 
nivel temporal a potentialului de paralelism la nivel de instructiune existent 
în programe, acesta a coborât, la procesarea de tip pipeline, pâna la 
valoarea limita egala cu 1. Strapungerea acestui "zid sonic" spre valori 
subunitare de cicli per instructiune sa produs cu mai bine de 10 ani în 
urma, metrica adaptându-se si ea la exprimarea de Instructiuni-Per-Ciclu 
(IPC). Actualele valori, în jur de trei instructiuni per ciclu, sunt obtinute pe 
arhitecturi de microprocesoare de tip superscalar (mai multe unitati 
functionale integrate în structura caii de date) acestea exploatând la nivel 
spatial potentialul de paralelism la nivel de instructiune. 


În stadiul actual, cresterile de viteza de procesare au o mai mica 
determinare prin software, componenta preponderenta în aceste cresteri 
fiind adusa de catre microprocesor (procesorul si compilatorul sunt privite 
ca un tot integrat). lar când astazi sunt prezentate cresterile de performanta 
ale procesorului se mai pastreaza opinia, corecta înainte de anii '80, ca 
aceste cresteri se datoreaza în mare parte tehnologiei de integrare. Fals! În 
ultimii aproape 15 ani aportul în cresterea performantelor procesoarelor 
adus de inovatiile arhitecturale are o pondere cu mult mai mare decât cel 
obtinut prin îmbunatatirile tehnologiei de integrare (exprimabile prin legea 
lui Moore). lar aceste inovatii arhitecturale, care s-ar parea ca nu au ajuns 
înca la un nivel de saturatie, se bazeaza pe exploatarea paralelismului 
instructiunilor atât la nivel temporal cât si spatial. lata de ce aceasta carte 
care abordeaza conceptele moderne de arhitectura ale microprocesoarelor 
este oportuna si necesara. 

Poate unii cititori, privind titlul cartii sau rasfoind-o, se întreaba 
daca este necesara o astfel de carte când la noi nu se produc 
microprocesoare si este exclus, chiar in viitor, sa-i concuram pe cei 
consacrati acestui domeniu. DA, este foarte necesara pentru cei care se 
instruiesc în universitati sau deja profeseaza în domeniul ingineriei 
calculatoarelor ori în domenii conexe acestuia sau pentru cei care doresc o 
documentare fundamentala în arhitectura microprocesoarelor. 

Instruirea universitara în domeniul ingineriei calculatoarelor si cele 
conexe acestuia trebuie sa asigure însusirea conceptelor arhitecturale 
fundamentale, aceste concepte devenind apoi instrumente operante pentru 
conceptie si cercetare. Metoda de instruire printr-o abordare descriptiva cu 
focalizare pe un studiu de caz (când timpul de viata comerciala al unui 
procesor actual este de circa 3 ani) este cu penetratie scurta din punct de 
vedere teoretic cât si practic. Aceasta carte poate fi un suport pentru primul 
mod de instruire. Ea este prima lucrare scrisa în limba româna care îmbina 
creativ fundamentele arhitecturilor moderne de microprocesor cu evaluarile 
de tip cantitativ obtinute prin simulari. 

Lucrarea poate fi o provocare sau un ajutor si pentru cei care 
abordeaza la nivel de conceptie arhitectura microprocesoarelor. La fel, unii 
cititori pot sa afirme ca, actual, privilegiul conceptiilor novatoare din 
arhitectura îl detin doar câteva scoli de cercetare grupate la câteva din 
universitatile americane de vârf, iar proiectarea si producerea 
microprocesoarelor de succes comercial este monopolul câtorva firme 
supertehnologizate, ceea ce este perfect adevarat. Dar ... exista loc sub 
soare pentru toata lumea. În ce sens ? Tehnicile de proiectare automata în 


electronica (EDA — Electronic Design Automation Techniques) cu 
performante la zi, sunt deja accesibile si la noi. Folosind aceste tehnici se 
pot proiecta microsisteme care de cele mai multe ori sunt "croite" pentru o 
aplicatie dedicata, deci sunt non-standard. Un microsistem rezulta printr-o 
integrare pe acelasi chip a unor componente / blocuri standard, care se 
supun regimului de proprietate intelectuala, si a unor componente 
concepute special. Indiferent de raportul dintre numarul de componente 
standard si numarul de componente speciale, integrate într-un microsistem, 
proiectantul acestuia trebuie sa aiba o profesionalitate similara celui care 
proiecteaza arhitecturi de microprocesor. Acum, aceste microsisteme pot fi 
proiectate si aici, apoi implementate la orice turnatorie de siliciu din lume, 
deci producerea microsistemului se poate realiza fara a avea la noi o astfel 
de capacitate tehnologica de integrare, despre care am amintit înainte cât 
costa. 

Aceasta carte este o cercetare bibliografica la zi privind aspectele 
actuale ale arhitecturii microprocesoarelor întretesuta cu multe completari 
si contributii originale, rodul unei munci a autorului în acest domeniu de 
peste un deceniu. Este recomandata a fi utilizata în universitati de studentii 
din anii terminali, de studentii masteranzi si de cei doctoranzi din domeniul 
ingineriei calculatoarelor si domenii conexe; este utila de asemenea 
inginerilor si cercetatorilor. 


Prof.univ.dr.ing. Gheorghe 
Toacse 
Brasov, martie 1999 


1. INTRODUCERE 


Aceasta carte abordeaza probleme apartinând arhitecturilor de calcul care 
exploateaza paralelismul existent la nivelul instructiunilor masina într-un program 
(Instruction Level Parallelism- ILP). Aceste arhitecturi sunt caracterizate de o 


procesare agresiva, neconventionala, a instructiunilor masina pe baza 


paralelismului realizat atât la nivel temporal (“pipeline”) cât si la nivel “spatial” 
(unitati functionale multiple). 

O remarca importanta ar fi aceea ca domeniul este deosebit de fecund si deci 
cu un caracter mai degraba evolutionist, constructiv, decat revolutionar [Hen96]. 
Aceasta afirmatie este justificata si de succesele comerciale deosebite, 
implementate în special în cadrul microprocesoarelor avansate actuale, într-un timp 
extrem de scurt de la aparitia acestor concepte la nivel de cercetare. 

Din punct de vedere istoric, primele procesoare neconventionale au fost cele 
din dotarea supercomputerelor CDC-6600 (1964), considerat a fi primul calculator 
pipeline - vectorial viabil, si respectiv IBM-360/91 (1966), considerat ca fiind 
precursorul calculatoarelor cu executie multipla a instructiunilor. Asadar, CDC- 
6600 - precursorul supercomputerelor de tip Cray - era caracterizat de o executie 
paralela a instructiunilor la nivel temporal, iar IBM-360/91 de o procesare paralela 
atât din punct de vedere temporal cât si spatial, prin exploatarea inovatoare, în 


paralel, a unor unitati functionale multiple în procesorul de virgula mobila [Pat82, 


Tom67]. 

fn anul 1981 s-a anuntat la Universitatea Berkeley, S.U.A., realizarea 
primului microprocesor VLSI (Very Large Scale Integration) bazat pe procesarea 
pipeline a instructiunilor si cu set optimizat de instructiuni in vederea facilizarii 
implementarii limbajului C, microprocesor numit Berkeley I RISC [Pat82]. 
Acronimul RISC (Reduced Instruction Set Computer) a fost propus de catre 
profesorul David Patterson, coordonatorul proiectului. Dupa parerea autorului 
acestei carti, la ora actuala, termenul de RISC este inexact daca este înteles "add 
literam", mai potrivit din punct de vedere semantic ar fi cel de procesor scalar 
pipeline cu set optimizat de instructiuni, în vederea procesarii aplicatiilor propuse. 

Multe dintre ideile arhitecturii RISC se datoreaza, dupa cum chiar creatorii o 
arata, pionierilor care au proiectat supercomputerul CDC-6600 (Seymour Cray, 
Thornton, etc.) si respectiv minisistemului IBM 801, o masina RISC proiectata la 
începutul anilor *80 pe baza ideilor novatoare ale lui John Cocke. Totusi s-au adus 
si idei fundamental noi, precum cele legate de optimizarea setului de instructiuni în 
vederea implementarii limbajelor de nivel înalt, simplificarii unitatii de comanda, 
optimizarii instructiunilor mari consumatoare de timp, etc. De altfel, aceste idei au 
readus în discutie fundamentele proiectarii calculatoarelor numerice [Pat82], care 
prin prisma cercetarilor unor pionieri precum Eckert, Mauchly, von Neumann, 


Amdahl, Flynn, Cray si Wilkes, pareau sa fie satisfacatoare. Ideea novatoare 


principala a constat in optimizarea structurii hardware bazat pe cerintele impuse 
prin aplicatiile utilizatorului. 

Limitarea principiala a performantei arhitecturilor RISC la o rata de 
procesare de doar o instructiune / ciclu masina sau tact, a adus incepand din anul 
1987 in discutie un concept si mai indraznet: acela de masina cu executii multiple 
ale instructiunilor (MEM - Multiple Instruction Execution Machine). Aceste 
masini au drept principal deziderat depasirea barierei de o instructiune / tact si 
atingerea unor rate de procesare de mai multe instructiuni / tact. Aceste procesoare 
extind paralelismul temporal de tip pipeline la unul spatial bazat pe aducerea si 
executia simultana a mai multor instructiuni masina. Evident ca acest model 
presupune existenta mai multor unitati functionale de procesare. Arhitecturile 
MEM sunt implementate la ora actuala în principal în doua variante distincte: 
procesoare superscalare si respectiv procesoare VLIW (Very Long Instruction 
Word). 

În varianta superscalara cade în sarcina hardului sa verifice în mod dinamic 
"run - time") independenta instructiunilor aduse si sa le lanseze în executii 
multiple spre unitatile de executie pipeline-izate. Desigur ca aceste arhitecturi au o 
complexitate hardware deosebita determinata de detectia si solutionarea 
hazardurilor între instructiuni, precum si de exploatarea paralelismului determinat 
în principal prin gradul de independenta între aceste instructiuni. De exemplu, 


complexitatea logicii de detectie a (in)dependentei instructiunilor ce se doresc a fi 


lansate in executie simultan, creste proportional cu patratul numarului de 
instructiuni din bufferul de prefetch. De asemenea, ele sunt limitate in posibilitatea 
de a exploata paralelismul la nivelul instructiunilor, de capacitatea limitata a 
acestui buffer de prefetch, cu influente negative asupra performantelor [Joh91, 
Sto93]. Exista implementari superscalare atat in filosofie RISC cat si CISC. 

La procesoarele VLIW, mult mai rare decat cele superscalare deocamdata cel 
putin pe plan comercial, cade in sarcina compilatorului sa reorganizeze programul 
original in scopul "impachetarii" într-o singura instructiune multipla a mai multor 
instructiuni RISC primitive si independente, care vor fi alocate unitatilor de 
executie în conformitate stricta cu pozitia lor în instructiunea multipla. Un procesor 
VLIW aduce mai multe instructiuni primitive simultan si le lanseaza în executie tot 
simultan spre unitatile functionale. Spre deosebire de modelul superscalar, aici 
rutarea instructiunilor spre diferitele unitati de executie, se face static, anterior 
executiei prin chiar procesul de "impachetare", de catre o componenta a 
compilatorului zisa scheduler sau reorganizator. Asadar aici paralelismul este 
exploatat în mod explicit de catre compilator (EPIC - Explicitly Parallel 
Instruction Computing). Si acest model arhitectural are dezavantaje precum: 
incompatibilitati soft între variante succesive de procesoare, necesitati sporite de 
memorare ale programelor, dificultati tehnologice legate de numarul mare de 


terminale, etc. Avantajul principal fata de modelul superscalar consta în simplitatea 


hardware, in special in ceea ce priveste logica de detectie a hazardurilor si lansare 
în executie. 

Aceste masini MEM sunt incadrabile in clasa MIMD (Multiple Instruction 
Multiple Data) [Flyn96], insa trebuie aratat ca ele nu se confunda cu sistemele 
multiprocesor care exploateaza paralelismul diverselor task-uri (coarse grain 
parallelism) si care sunt totusi principalele componente ale acestei clase 
arhitecturale. Masinile MEM exploateaza paralelismul la nivelul instructiunilor 
masina dintr-un anumit program, dupa cum am aratat (fine grain parallelism). Spre 
deosebire de MIMD - urile propriu zise, ele detin avantajul de a mentine practic 
nemodificata viziunea conventionala, secventiala, a programatorului în limbaj 
evoluat. Aceasta calitate le-a asigurat de altfel un enorm succes comercial acestor 
arhitecturi, altfel, si ele neconventionale. O oarecare ironie face ca aceste modele 
evolutive sa se fi dovedit mai eficiente si uzitate în exploatarea paralelismului decât 
alte structuri considerate revolutionare, precum masivele de procesare de exemplu, 
care - în ciuda unor cercetari asidue si îndelungate - au produs un impact practic 
neglijabil asupra utilizatorului obisnuit. Desigur însa, limitari fundamentale 
specifice tuturor sistemelor paralele, precum legea lui Amdahl si altele, actioneaza 
defavorabil si asupra acestor arhitecturi ILP. Caracteristic arhitecturilor MEM din 
generatia arhitecturala actuala, considerata a fi cea de a III-a, este ca lucreaza dupa 
un mecanism de tip "producator - consumator”. Mai precis, în fiecare ciclu se 


desfasoara în mod simultan doua procese independente: unul de aducere a 


instructiunilor din memorie in bufferul de prefetch (producatorul) si un altul de 
lansare in executie a acestor instructiuni din acel buffer (consumatorul). 
Mecanismul de reactie între consumator si producator este realizat prin 
instructiunile de ramificatie (branch). Generatia arhitecturala urmatoare de 
microprocesoare se va baza se pare si ea pe acelasi model doar ca se vor utiliza 
tehnici de procesare mai agresive precum cele bazate pe reutilizarea dinamica a 
instructiunilor care au mai fost aduse sau / si executate, pe memorii de mare 
capacitate integrate "on chip”, pe exploatarea paralelismului la nivelul mai masiv 
de "thread", etc. 

Caracteristic domeniului ILP este optimimizarea interfetei hardware - 
software a sistemului. Se porneste de la ideea ca masina hardware trebuie 
construita astfel încât sa execute optimal aplicatii reale, cât mai diverse si cât mai 
generale, scrise în limbaje de programare evoluate. Orice investigare prin prisma 
acestei idei, duce în final la legaturi directe, altfel de neimaginat, între caracteristici 
ale limbajului sau aplicatiei de nivel înalt si respectiv parametrii unor structuri 
hardware prin excelenta. Nu cred sa existe un alt domeniu al stiintei si ingineriei 
calculatoarelor în care sa se expliciteze mai bine legatura strânsa între aplicatia 
utilizatorului potential si respectiv un detaliu de proiectare hardware. Pentru 
aceasta, instrumentele de analiza si investigatie care trebuie construite, sunt 


complexe si cel mai adesea laborioase în implementare. 


Astfel într-o cercetare a acestui domeniu, sunt necesare instrumente precum: 
cross - compilatoare, schedulere pentru optimizarea codului obiect rezultat în urma 
compilarii, simulatoare complexe, benchmark-uri reprezentative a caror executie sa 
fie simulata, etc. Toate aceste instrumente de investigare este recomandabil sa fie 
dublate de metode analitice, teoretice, de descriere si modelare a structurilor 
cercetate. Dar poate mai importanta, ca peste tot, este abilitatea cercetatorului de a 
întrezari solutii la dificilele provocari ale domeniului sau chiar de a investiga 
probleme noi, neabordate înca. Prin fecunditatea sa la nivelul realizarilor si implicit 
cel al sumelor cheltuite la ora actuala pe plan mondial, se apreciaza ca domeniul 
cercetarii ILP se situeaza între primele 2-3 domenii de cercetare în stiinta 
calculatoarelor, în prezent. 

Aceasta lucrare constituie atât o cercetare bibliografica laborioasa si 
actualizata într-un domeniu abordat în premiera la noi dupa stiinta autorului, cât si 
o cercetare asupra unor probleme dificile, deschise, ale acestui domeniu pasionant, 
la care se încearca solutii originale. Relativ la termenii stiintifici si tehnici utilizati, 
acestia au fost în general preluati direct din literatura de specialitate, considerând 
acest fapt un "rau mai mic" decât traducerile în româneste deseori inexacte, alteori 
chiar nocive. Întelegerea acestei lucrari de catre cititor presupune familiarizarea 
acestuia cu domeniul arhitecturii sistemelor de calcul. Din acest motiv, prezentarea 


"teoriei" arhitecturilor ILP, se rezuma la capitolele 2 si 3, dar si aici notiunile 


arhitecturale de baza (memorii cache, memorie virtuala, etc.) sunt considerate ca 
fiind cunoscute, insistandu-se mai mult asupra celor mai pretentioase. 

Pe scurt, lucrarea este structurata astfel: 

În capitolul 2 se prezinta o sinteza originala asupra problematicii 
procesoarelor scalare pipeline cu set optimizat de instructiuni masina (RISC). Se 
prezinta principalele caracteristici arhitecturale ale acestor structuri de calcul, 
problemele implicate de metodele neconventionale (fata de modelul initial von 
Neumann) de procesare promovate precum si solutiile care se impun pentru 
eficientizarea lor. Se pune accent în prezentare pe dualitatea hardware - software 
necesara a fi optimizata în cadrul acestor arhitecturi pipeline. De asemenea se 
insista aici pe o prezentare critica, întocmita absolut "la zi", asupra problematicii 
predictiei ramificatiilor de program. În acest sens se arata ca paradigma actuala a 
predictiei ramificatiilor este insuficienta pentru marea performanta si se propun 
câteva solutii novatoare. 

În capitolul 3, ca o continuare fireasca, se abordeaza problematica mai 
generala a arhitecturilor de calcul de tip MEM. Similar, se definesc principiile 
executiilor multiple ale instructiunilor în cadrul structurilor superscalare si 
respectiv VLIW. Se prezinta apoi principalii algoritmi hardware si software 
propusi în vederea unei executii optimale, "Out of Order", a instructiunilor din 
program. De asemenea sunt scoase în evidenta problemele care apar, tehnicile si 


solutiile cele mai valoroase prezentate în literatura de specialitate la ora actuala. 


Tot aici se mai prezinta si câteva dintre conceptele care vor sta la baza noii 
generatii de microprocesoare avansate (arhitecturile TTA - Transport Triggered 
Architectures, trace - cache, reutilizarea executiei instructiunilor, procesarea 
vectoriala, etc.). 

În capitolul 4 se prezinta contributiile originale ale autorului în analiza de 
performanta si respectiv determinarea unor parametri optimali de proiectare, pentru 
diferite probleme deschise, de interes în arhitecturile MEM. În principiu, metodele 
propuse sunt de tip analitic, bazându-se în principal pe conceptele de vector de 
coliziune si respectiv automat finit. Complexitatea modelelor, vazute ca o 
alternativa de investigare la simularile foarte laborioase, este incomparabila cu 
aceea a simularilor si determina solutii pe baza unor metode relativ simple de 
analiza numerica. Metodele de investigare propuse sunt general aplicabile în 
contextul ILP, desi aici se prezinta ca exemplu doar o analiza particulara pe o 
tematica inedita: arhitecturi ILP tip Harvard vs. tip Princeton. 

Capitolul 5 constituie o cercetare si într-o masura o verificare pe baza de 
simulare a concluziilor extrase din metodele analitice dezvoltate în capitolul 
precedent. Mai precis, pe baza unor simulatoare special concepute, pe arhitecturi 
ILP originale si puternic parametrizabile, se abordeaza analiza unor arhitecturi 
cache separate pe instructiuni si date într-un procesor RISC superscalar (Harvard) 
Si respectiv unificate pe instructiuni si date (Princeton). Simulatoarele sunt astfel 


concepute, încât sa genereze parametrii optimi de proiectare relativ la interfata 


procesor - cache. Specific acestei investigatii este caracterul ei cantitativ. Principiul 
de baza al cercetarilor prezentate in acest capitol este cel al simularii de tip "trace 
driven", fundamental in practica acestui domeniu. Tot aici se investigheaza într-un 
mod pragmatic, cantitativ, eficienta unor concepte avansate integrate in cadrul 
arhitecturilor MEM, precum cele de cache-uri fara blocare (non - blocking), cache- 
uri de tip victima, instructiuni combinate, procesor specializat pe scriere, etc. 

În capitolul 6 sunt prezentate cercetari ale autorului cu privire la dificila 
problema a predictiei branch-urilor în cadrul arhitecturilor superscalare de 
procesoare. Mai întâi se prezinta o metoda analitica originala de evaluare a 
performantei schemelor de predictie de tip Branch Target Buffer, precum si o 
analiza bazata pe simulare "trace driven", a unor predictoare BTB si respectiv 
corelate pe 2 nivele, puternic parametrizabile, integrate într-o arhitectura 
superscalara, de asemenea parametrizabila. Metoda analitica genereaza în premiera 
o metrica de performanta globala si eficienta, pentru schemele BTB. Cercetarile 
bazate pe simulare, genereaza automat solutiile constructive optimale pentru 
schemele BTB si adaptive de predictie, integrate într-un mediu ILP general. În 
finalul capitolului se propune în premiera, ca o alternativa utila si interesanta, 
conceptul de predictor neuronal, aflat într-un stadiu de cercetare înca de catre autor. 

Capitolul 7 prezinta  investigatiile autorului relative la problema 
schedulingului în arhitecturile MEM. Astfel, se prezinta rezultatele obtinute in 


optimizarea basic-block-urilor cu ajutorul unui scheduler si simulator special 


concepute. De asemenea, se prezinta o cercetare, relativa la gradul teoretic de 
paralelism disponibil si exploatabil si respectiv la cuantificarea "barierelor" ce stau 
în calea atingerii acestui grad maximal de paralelism. Pe aceasta baza se 
concluzioneaza asupra principalelor tehnici de scheduling static, si nu numai, care 
trebuie imbunatatite în viitorul apropiat. Tot aici se prezinta sintetic câteva 
cercetari conexe de notorietate, asupra constrângerilor impuse în scheduling de 
catre instructiunile de ramificatie. 

Lucrarea se încheie cu o lista bibliografica a peste 150 de lucrari utilizate pe 
parcursul cercetarii si contine cca. 200 de figuri si tabele, dintre care peste 50% 
continând rezultatele cercetarilor efectuate de catre autor si respectiv 73 de relatii 
analitice. 

Concluziile acestei lucrari sugereaza în esenta, necesitatea unor analize 
teoretice mai profunde, mai generale si mai sistematizate în acest domeniu, dublate 
si verificate prin simulari laborioase. Aceasta dualitate de investigare de tip 
"analiza + simulare", a reprezentat esenta acestei investigatii. Cred ca acesta este 
un fapt pozitiv în abordarea domeniului ILP, aflat aproape exclusiv sub dominatia 
unor investigatii empirice, teoretic nu foarte mature, bazate practic exclusiv pe 
simulare si care nu ofera un cadru sistematizat si general de analiza. Asemenea 
simulari sunt inevitabil particulare si pot duce prin extrapolarea rezultatelor la 
concluzii gresite daca sunt utilizate în mod exclusiv si daca nu sunt dublate de o 


baza analitica relativ riguroasa. Desigur ca si aspectul reciproc este adevarat, 


modelarea si optimizarea hardware unui sistem de calcul exclusiv pe baza analitica 
fiind fara îndoiala o utopie pentru ca "intrarea" în arhitectura hardware o reprezinta 
ceva nebulos, situat între determinist si aleatoriu, numit program. Ce face acesta 
nimeni nu stie apriori pentru simplul motiv ca poate face practic orice. 

Cercetarile abordate în aceasta lucrare, multe dintre ele aflate în plina 
"desfasurare", ar putea fi continuate în scopul rezolvarii altor probleme deschise, 
interesante si conexe cu cele prezentate aici, pe care domeniul ILP le pune. De 
altfel asemenea sugestii sunt facute în mod explicit si concret pe parcursul 
prezentarii. 

Sper ca lucrarea sa se dovedeasca utila tuturor celor care doresc sa parcurga o 
abordare constructiva, pragmatica si nu doar descriptiva a domeniului arhitecturilor 
cu paralelism la nivelul instructiunilor masina. Consider ca este mare nevoie de 
asemenea abordari, care sa duca cititorul pe drumul de la "despre" la "in", adica de 
la "deschiderea care se închide" specifica descriptivului steril, la "închiderea care 
se deschide" a creativului, cum ar fi spus probabil filosoful de la Paltinis. Scopul 
principal al acestei modeste lucrari a fost acela de a arata ca arhitectura sistemelor 
de calcul avansate este un domeniu în care se poate si trebuie sa se cerceteze si în 
România, nu numai în tarile avansate tehnologic. În plus, literatura acestui domeniu 
trebuie sa iasa, daca se doreste a fi perceputa ca interesanta de catre specialistii 


nostri, de sub mantia descriptivului exclusiv, din pacate caracteristica multor 


abordari autohtone. Pentru ca, dupa cum se va putea sper întelege mai bine dupa 


lecturarea cartii, provocarile acestui domeniu ca de altfel a multora din stiinta si 
ingineria calculatoarelor, sunt in principal conceptuale, arhitecturale, si abia mai 
apoi si poate chiar într-o mai mica masura, tehnologice. lar documentarea la zi si 
deprinderea unor instrumente si mestesuguri de cercetare, nu mai constituie azi 
chiar asa mari probleme in România. Închei cu marturisirea scopului principal al 
acestei lucrari: domeniul paralelismului redus si nu numai, este abordabil aici, 


acum! 


2. PROCESOARE PIPELINE SCALARE CU SET OPTIMIZAT DE 
INSTRUCTIUNI 


2.1. MODELUL RISC. GENEZA SI CARACTERISTICI GENERALE 


Microprocesoarele RISC (Reduced Instruction Set Computer) au aparut ca 
o replica la lipsa de eficienta a modelului conventional de procesor de tip CISC 
(Complex Instruction Set Computer). Multe dintre instructiunile masina ale 
procesoarelor CISC sunt foarte rar folosite in softul de baza, cel care 
implementeaza sistemele de operare, utilitarele, translatoarele, etc. Lipsa de 
eficienta a modelului conventional CISC a fost pusa in evidenta prin anii '80 de 
arhitecturi precum INTEL 80x86, MOTOROLA 680x0, iar in domeniul 
(mini)sistemelor in special de catre arhitecturile VAX-11/780 si IBM - 360,370, 


cele mai cunoscute la acea vreme. 


Modelele CISC sunt caracterizate de un set foarte bogat de instructiuni - 
masina, formate de instructiuni de lungime variabila, numeroase moduri de 
adresare deosebit de sofisticate, etc. Evident ca aceasta complexitate arhitecturala 
are o repercursiune ne gativa asupra performantei masinii. 

Primele microprocesoare RISC sau proiectat la Universitatile din Stanford 


(coordonator prof. John Hennessy) si respectiv Berkeley (coordonator prof. David 


Patterson, cel care a si propus denumirea RISC), din California, USA (1981) 
[Pat82]. Spre deosebire de CISC-uri, proiectarea sistemelor RISC are in vedere ca 
înalta performanta a procesarii se poate baza pe simplitatea si eficacitatea 
proiectului ("Keep it simple!). Strategia de proiectare a unui microprocesor RISC 
trebuie sa tina cont de analiza aplicatiilor posibile pentru a determina operatiile cele 
mai frecvent utilizate, precum si optimizarea structurii hardware în vederea unei 
executii cât mai rapide a instructiunilor. Dintre aplicatiile specifice sistemelor 
RISC se amintesc: conducerea de procese în timp real, procesare de semnale 
(DSP), calcule stiintifice cu viteza ridicata, grafica de mare performanta, elemente 
de procesare în sisteme multiprocesor si alte sisteme cu prelucrare paralela, etc. 

Caracteristicile de baza ale modelului RISC sunt urmatoarele [DEC91, Pat82, 
Hen96]: 

-Timp de proiectare si erori de constructie mai reduse decat la variantele 
CISC. 

-Unitate de comanda hardware in general cablata, cu firmware redus sau 
deloc, ceea ce mareste rata de executie a instructiunilor. 

-Utilizarea tehnicilor de procesare pipeline a instructiunilor, ceea ce implica o 
rata teoretica de executie de o instructiune / ciclu, pe modelele de procesoare care 
pot lansa in executie la un moment dat o singura instructiune (procesoare scalare). 

-Memorie sistem de înalta performanta, prin implementarea unor arhitecturi 


avansate de memorie cache si MMU (Memory Management Unit ). De asemenea 


contin mecanisme hardware de memorie virtuala bazate in special pe paginare ca si 
sistemele CISC de altfel. 

-Set relativ redus de instructiuni simple, majoritatea fara referire la memorie 
si cu putine moduri de adresare. În general, doar instructiunile LOAD / STORE 
sunt cu referire la memorie (arhitectura tip LOAD / STORE). La implementarile 
recente caracteristica de "set redus de instructiuni” nu trebuie înteleasa add literam 
ci mai corect în sensul de set optimizat de instructiuni în vederea implementarii 
aplicatiilor propuse (în special implementarii limbajelor de nivel înalt - C, Visual 
C++, Pascal, etc.). 

-Datorita unor particularitati ale procesarii pipeline (în special hazardurile pe 
care aceasta le implica), apare necesitatea unor compilatoare optimizate zise si 
reorganizatoare sau schedulere, cu rolul de a reorganiza programul sursa pentru a 
putea fi procesat optimal din punct de vedere al timpului de executie. 

-Format fix al instructiunilor, codificate în general pe un singur cuvânt de 32 
biti, mai recent pe 64 biti (Alpha 21164, Power PC-620, etc.). 

-Necesitati de memorare a programelor mai mari decât în cazul 
microsistemelor conventionale, datorita  simplitatii instructiunilor cât si 
reorganizatoarelor care pot actiona defavorabil asupra "lungimii" programului 
obiect. 

-Set de registre generale substantial mai mare decât la CISC-uri, în vederea 


lucrului "in ferestre” (register windows), util în optimizarea instructiunilor CALL / 


RET. Numarul mare de registre generale este util si pentru marirea spatiului intern 
de procesare, tratarii optimizate a evenimentelor de exceptie, modelului ortogonal 
de programare, etc. Registrul RO este cablat la zero în majoritatea implementarilor, 
pentru optimizarea modurilor de adresare si a instructiunilor. 

Microprocesoarele RISC scalare reprezinta modele cu adevarat evolutive în 
istoria tehnicii de calcul. Primul articol despre acest model de procesare a aparut în 
anul 1981 (David Patterson, Carlo Sequin), iar peste numai 6-7 ani toate marile 
firme producatoare de hardware realizau microprocesoare RISC scalare în scopuri 
comerciale sau de cercetare. Performanta acestor microprocesoare creste în medie 


cu cca. 75% în fiecare an. 


2.2. SET DE INSTRUCTIUNI. REGISTRI INTERNI LA MODELUL 
ARHITECTURAL RISC 


În proiectarea setului de instructiuni aferent unui microprocesor RISC 
intervin o multitudine de consideratii dintre care se amintesc [DECOI, Pat94, 
Hen96, Pat82]: 

a). Compatibilitatea cu seturile de instructiuni ale altor procesoare pe care s- 
au dezvoltat produse software consacrate (compatibilitatea de sus în jos, valabila de 
altfel si la CISC-uri). Portabilitatea acestor produse pe noile procesoare este 
conditionata de aceasta cerinta care vine în general în contradictie cu cerintele de 


performanta ale sistemului. 


b). În cazul microprocesoarelor, setul de instructiuni este in strânsa 
dependenta cu tehnologia folosita, care de obicei limiteaza sever performantele 
(constrângeri legate de aria de integrare, numarul de pini, cerinte restrictive 
particulare ale tehnologiei, etc.). 

c). Minimizarea complexitatii unitatii de comanda precum si minimizarea 
fluxului de informatie procesor - memorie. 

d). În cazul multor microprocesoare RISC setul de instructiuni masina este 
ales ca suport pentru implementarea unor limbaje de nivel înalt. 

Setul de instructiuni al unui microprocesor RISC este caracterizat de 
simplitatea formatului precum si de un numar limitat de moduri de adresare. De 
asemenea, se urmareste ortogonalizarea setului de instructiuni. Deosebit de 
semnificativ în acest sens, este chiar primul microprocesor RISC numit RISC I 
Berkeley [Pat82]. Acesta detinea un set de 31 instructiuni grupate în 4 categorii: 
aritmetico-logice, de acces la memorie, de salt / apel subrutine si speciale. 
Microprocesorul detinea un set logic de 32 registri generali pe 32 biti. Formatul 
instructiunilor de tip registru-registru si respectiv de acces la memorie (LOAD / 


STORE) este dat în figura 2.1: 


OPCODE (7) | SCC (1) | DEST (5) | SOURCE 1 (5) | IMM [1)] SOURCE 2 (13) 


Figura 2.1. Formatul instructiunii la Berkeley I RISC. 


Campul IMM = 0 arata ca cei mai putini semnificativi (c.m.p.s.) 5 biti ai 
câmpului SOURCE2 codifica al 2-lea registru operand. 

Câmpul IMM = 1 arata ca SOURCE2 semnifica o constanta pe 13 biti cu 
extensie semn pe 32 biti. 

Câmpul SCC (Store Condition Codes) semnifica validare / invalidare a 
activarii indicatorilor de conditie, corespunzator operatiilor aritmetico-logice 
executate. 

În ciuda setului redus de instructiuni al procesorului Berkeley RISC 1, acesta 
poate sintetiza o multitudine de instructiuni aparent "inexistente" la acest model. 
Practic nu se "pierd" instructiuni ci doar "opcode"- uri, si ca o consecinta, în plus se 
simplifica substantial logica de decodificare si unitatea de comanda [Pat91, Pat94, 
Vin96]. 

Potential, programele RISC pot contine mai multe CALL-uri decât cele 
conventionale, în principal pentru ca instructiunile complexe implementate în 
procesoarele CISC vor fi subrutine în cazul procesoarelor RISC. Din acest motiv 
procedura CALL / RET se impune a fi cât mai rapida în procesarea RISC. Modelul 
utilizarii registrelor în fereastre îndeplineste acest deziderat prin reducerea 
traficului de date cu memoria sistem (Berkeley I RISC, SUN-SPARC, etc.) 
Principiul de lucru consta în faptul ca fiecare instructiune CALL aloca o noua 
fereastra de registre pentru a fi utilizata de procedura apelata, în timp ce o 


instructiune RET va restaura vechea fereastra de registre. Se considera spre 


exemplificare 3 procese soft, care se apeleaza imbricat ca in figura urmatoare 


(Fig.2.2) : 


Proces A CALL 
RET 


CALL 


Proces B 


Figura 2.2. Lucrul in ferestre de registre 


Statistici deosebit de serioase arata ca in cadrul implementarilor de limbaje 
HLL (High Level Languages) instructiunile CALL / RET sunt frecvent folosite si 
totodata cele mai mari consumatoare de timp (ocupa între 5%-45% din referirile la 
memorie). Fiecare proces are alocata o fereastra de registri constând în 3 seturi 
distincte : HIGH, LOCAL si LOW. Registrele globale RO - R9 contin parametrii 
globali ai proceselor soft. Acesti registri sunt comuni tuturor proceselor si nu se 


salveaza / restaureaza niciodata. 


Registrii locali R16 - R25 sunt utilizati pentru memorarea scalarilor locali ai 
procesului curent. O instructiune CALL determina ca registrele LOW din procesul 
master apelant sa devina registre HIGH in procesul SLAVE apelat. Odata cu 
schimbarea ferestrelor, o instructiune CALL memoreaza registrul PC într-un 
anumit registru al noii ferestre. 

O instructiune RET determina o actiune reciproca, adica registrii HIGH ai 
procesului curent vor deveni registrii LOW pentru procesul MASTER în care se 
revine. 

În registrii LOW procesul MASTER transmite automat parametrii spre 
procesul SLAVE, respectiv din acesti registri procesul MASTER curent preia 
rezultatele de la procesul SLAVE apelat. În registrii HIGH procesul curent 
memoreaza rezultatele, respectiv din acesti registri procesul curent preia parametrii 
transmisi de catre procesul MASTER apelant. Se observa ca aceste comutari de 
ferestre au drept principal scop eliminarea stivei si deci a timpului consumat cu 
accesarea acesteia. 

Referitor la cele de mai sus apar 2 tipuri de exceptii ca fiind posibile: 

- "window overflow" (WO) poate sa apara dupa o instructiune CALL în care 
schimbarea setului de registri LOW ai procesului curent în registrii HIGH ai 
procesului viitor devine imposibila datorita numarului limitat de registri generali 


implementati; 


- "window underflow" (WU) poate sa apara dupa o instructiune RET care 
determina ca schimbarea registrilor HIGH ai procesului curent in registrii LOW ai 
procesului viitor sa devina imposibila. 

Dintre microprocesoarele RISC consacrate, cele din familia SPARC 
(sistemele SUN) au implementat un set de maxim 32 ferestre a câte 32 registri 
fiecare. Numarul mare de registri generali necesari pentru implementarea 
conceptului de "register windows" implica reducerea frecventei de tact a 
procesorului, fapt pentru care conceptul nu este implementat decât rar în 
microprocesoarele RISC comerciale. Studii statistice realizate înca din perioada de 
pionierat de catre Halbert si Kessler, arata ca daca procesorul detine 8 ferestre de 
registri, exceptiile WO si WU vor apare în mai putin de 1% din cazuri. Evident ca 
supraplasarea trebuie evitata în cadrul rutinei de tratare a exceptiei prin trimiterea / 
receptionarea parametrilor proceselor în / din buffere de memorie dedicate (stive). 

De precizat ca setul larg de registri generali este posibil de implementat la 
microprocesoarele RISC prin prisma tehnologiilor VLSI (Very Large Scale 
Integration) disponibile (HC-MOS, ECL, GaAs, etc.), întrucât unitatea de 
comanda, datorita simplitatii ei, ocupa un spatiu relativ restrans (la Berkeley RISC 
I de ex., ocupa doar aproximativ 6% din aria de integrare). Restul spatiului ramâne 
disponibil pentru implementarea unor suporturi de comunicatie interprocesor (ex. 


transputere), memorii cache, logica de management al memoriei, set registri 


generali extins, arii sistolice specializate de calcul (la DSP-uri, reuroprocesoare), 


etc. 


2.3. ARHITECTURA SISTEMULUI DE MEMORIE LA 
PROCESOARELE RISC 


Principalele caracteristici ale sistemului de memorie aferent unui sistem 
RISC sunt preyentate succint in continuare. Astfel, in general microprocesoarele 
RISC detin un management intern de memorie (MMU- Memory Management 
Unit) în majoritatea implementarilor. MMU-ul are rolul de a translata adresa 
virtuala emisa de catre microprocesor într-o asa numita adresa fizica de acces la 
memoria principala si respectiv de a asigura un mecanism de control si protectie - 
prin paginare sau / si segmentare a memoriei - a accesului la memorie. În general, 
MMU lucreaza prin paginare în majoritatea implementarilor cunoscute, oferind si 
resursele hardware necesare mecanismelor de memorie virtuala. De asemenea, 
sistemele RISC detin memorii cache interne si externe cu spatii în general separate 
pentru instructiuni si date (arhitecturi Harvard de memorie) si structuri de tip DWB 
(Data Write Buffer) cu rol de gestionare a scrierii efective a datelor în memoria 
sistem, prin degrevarea totala a procesorului propriu - zis. Pentru a asigura coerenta 
si consistenta datelor scrise în cache, acestea trebuie scrise la un moment dat si în 
memoria principala. În scopul eliberarii microprocesorului de acest lucru, DWB 


captureaza data si adresa emise de catre microprocesor si executa efectiv scrierea în 


memoria cache sau in cea principala, permitând astfel microprocesorului sa-si 
continue activitatea fara sa mai astepte pâna când data a fost efectiv scrisa in 
memoria principala. Asadar, DWB se comporta ca un mic procesor de iesire 
lucrând în paralel cu microprocesorul. Arhitectura de principiu a memoriei unui 


sistem RISC este caracterizata în figura 2.3: 


microprocesor RISC 
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Figura 2.3. Arhitectura de memorie tip Harvard la procesoarele RISC 


În afara spatiilor separate de instructiuni si date si a procesorului de iesire 
(DWB) nu exista alte probleme majore specifice microprocesoarelor RISC în 
arhitectura sistemelor de memorie. În principiu, ierarhizarea sistemului de memorie 
este aceeasi ca si la sistemele CISC (memorii cache, memorie virtuala). Nu intram 


aici în detalii teoretice legate de organizarea cache-urilor, a mecanismelor de 


memorie virtuala etc., întrucât aceste probleme sunt similare cu cek de la sistemele 
CISC, fiind deci foarte cunoscute si bine documentate bibliografic [Hen96, Sto93, 
Sta96]. 

Problema majora a sistemelor de memorie pentru ambele variante consta în 
decalajul tot mai accentuat între performanta microprocesoarelor care creste anual 
cu 50 -75% si respectiv performanta tehnologica a memoriilor (latenta) care are o 
rata de crestere de doar 7% pe an. Prin urmare acest "semantic gap" microprocesor 
- memorie reprezinta o provocare esentiala pentru îmbunatatirea performantelor 
arhitecturilor de memorie aferente arhitecturilor actuale de procesoare. În caz 
contrar, având în vedere frecventele de tact actuale ale microprocesoarelor (400 - 
800 MHz) si timpii de acces ai memoriilor tip DRAM (cca. 50 ns la ora actuala - 
1998), sistemul de calcul va functiona practic "cu frâna de mâna trasa”. Cercetarea 
acestei interfete procesor - cache, într-un mod pragmatic si cantitativ, va constitui 


un obiectiv major al acestei monografii. 


2.4. PROCESAREA PIPELINE ÎN CADRUL PROCESOARELOR 
SCALARE 


Cea mai importanta caracteristica arhitecturala a acestor microprocesoare 
RISC scalare o constituie procesarea pipeline a instructiunilor si datelor. În fapt, 
aproape toate celelalte caracteristici arhitecturale ale RISC-urilor au scopul de a 


adapta structura procesorului la procesarea pipeline. Acest concept a migrat de la 


sistemele mari de calcul la microprocesoare datorita progresului tehnologiei 
microprocesoarelor, caracterizat prin "legea lui G. Moore". Toate 
supercalculatoarele au implementat acest concept. Din punct de vedere istoric 
primul calculator pipeline viabil a fost - la acea vreme - supersistemul CDC 6600 


(firma Control Data Company, sef proiect Seymour Cray, 1964). 


2.4.1. DEFINIREA CONCEPTULUI DE ARHITECTURA PIPELINE 
SCALARA 


Tehnica de procesare pipeline reprezinta o tehnica de procesare paralela a 
informatiei prin care un proces secvential este divizat în subprocese, fiecare 
subproces fiind executat într-un segment special dedicat si care opereaza în paralel 
cu celelalte segmente. Fiecare segment executa o procesare partiala a informatiei. 
Rezultatul obtinut în segmentul i este transmis în tactul urmator spre procesare 
segmentului (i+1). Rezultatul final este obtinut numai dupa ce informatia a parcurs 
toate segmentele, la iesirea ultimului segment. Denumirea de pipeline provine de la 
analogia cu o banda industriala de asamblare. Este caracteristic acestor tehnici 
faptul ca diversele procese se pot afla în diferite faze de prelucrare în cadrul 
diverselor segmente, simultan. Suprapunerea procesarilor este posibila prin 
asocierea unui registru de încarcare (latch) fiecarui segment din pipeline. Registrele 
produc o separare între segmente astfel încât fiecare segment sa poata prelucra date 


separate (vezi Fig.2.4). 


Figura 2.4. Structura de procesare tip pipeline. 


În figura 2.4 sau notat prin Ti - registrii tampon iar prin Ni - nivelele de 
prelucrare (combinationale sau secventiale). 

Este evident ca nivelul cel mai lent de prelucrare va stabili viteza de lucru a 
benzii. Asadar, se impune in acest caz partitionarea unui eventual proces mai lent 
in subprocese cu timpi de procesare cvasiegali si interdependente minime. Exista 2 
solutii principiale, discutate în literatura, de a compensa întârzierile diferite pe 


diversele nivele de prelucrare [Pop92]: 


IN == OUT 
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Figura 2.5. Balansarea unei structuri pipeline prin divizarea nivelului lent 


Prima solutie, zisa de "balansare a benzii", necesita circuite suplimentare si 
poate fi realizata doar cu conditia ca sarcinile alocate respectivului nivel sa poata fi 
descompuse, ca in figura 2.5. O a doua solutie, se bazeaza pe conectarea in paralel 
a unui alt nivel cu aceeasi întârziere ca cel mai lent. Si aici trebuiesc circuite 
suplimentare. In plus, apare problema sincronizarii si controlului nivelelor care 
lucreaza in paralel. Solutia aceasta este utilizata cand sarcinile alocate nivelului mai 


lent nu mai pot fi descompuse (vezi Fig.2.6). 


© 


Figura 2.6. Balansare prin conectarea unui nivel lent în paralel 


În Tact (i) informatia se trimite spre procesare nivelului urmator pe calea A. 
În Tact (i+1) informatia se trimite în mod analog pe calea B, implementându-se 
deci o demultiplexare. 

Se defineste rata de lucru R a unei benzi de asamblare ca fiind numarul de 
procese executate în unitatea de timp T (ciclu masina sau tact). Considerând m 
posturi de lucru prin care trec n procese, rezulta ca banda le va executa într-un 


interval de timp Dt = (m + n -1) * T. Normal, având în vedere ca m*T este timpul 


de "setup" al benzii, adica timpul necesar terminarii primului proces. Asadar, rata 
de executie a unei benzi prin care trec n procese este: 
Ry = n/ (m4tn-1)T (2.1) 
Rata ideala este de un proces per ciclu, intrucat: 


R= lim Ry= WT (2.2) 


noo 
Dupa cum se va arata in continuare, aceasta rata teoretica nu se va putea 
atinge in practica, nu numai datorita faptului ca se prelucreaza un numar finit de 
procese si datorita timpului de "setup", ci mai ales datorita unor blocaje in 


functionarea normala a benzii numite hazarduri. 


2.4.2. PRINCIPIUL DE PROCESARE INTR-UN PROCESOR PIPELINE 


Procesarea pipeline a instructiunilor reprezinta o tehnica de procesare prin 
intermediul careia fazele (ciclii) aferente multiplelor instructiuni sunt suprapuse în 
timp. Se întelege printr-o faza aferenta unei instructiuni masina o prelucrare 
atomica a informatiei care se desfasoara dupa un algoritm implementat în hardware 
(firmware) si care dureaza unul sau mai multi tacti. În acest sens se exemplifica: 
faza de aducere (fetch) a instructiunii, faza de decodificare, faza de executie, faza 
de citire / scriere data, etc. Arhitectura microprocesoarelor RISC este mai bine 
adaptata la procesarea pipeline decât cea a sistemelor conventionale CISC, datorita 
instructiunilor de lungime fixa, a modurilor de adresare specifice, a structurii 


interne bazate pe registre generale, etc. Microprocesoarele RISC uzuale detin o 


structura pipeline de instructiuni intregi pe 4 - 6 nivele. De exemplu, 
microprocesoarele MIPS au urmatoarele 5 nivele tipice: 

1. Nivelul IF (instruction fetch) - se calculeaza adresa instructiunii ce trebuie 
citita din cache-ul de instructiuni sau din memoria principala si se aduce 
instructiunea; 

2. Nivelul RD (ID) - se decodifica instructiunea adusa si se citesc operanzii 
din setul de registri generali. In cazul instructiunilor de salt, pe parcursul acestei 
faze se calculeaza adresa de salt; 

3. Nivelul ALU - se executa operatia ALU asupra operanzilor selectati in 
cazul instructiunilor aritmetico-logice; se calculeaza adresa de acces la memoria de 
date pentru instructiunile LOAD / STORE; 

4. Nivelul MEM - se acceseaza memoria cache de date sau memoria 
principala, insa numai pentru instructiunile LOAD / STORE. Acest nivel pe functia 
de citire poate pune probleme datorate neconcordantei intre rata de procesare si 
timpul de acces la memoria principala. Rezulta deci ca intr-o structura pipeline cu 
N nivele, memoria trebuie sa fie în principiu de N ori mai rapida decât într-o 
structura de calcul conventionala. Acest lucru se realizeaza prin implementarea de 
arhitecturi de memorie rapide (cache, memorii cu acces întretesut, etc.). Desigur ca 
un ciclu cu MISS în cache pe acest nivel ( ca si pe nivelul IF de altfel), va 
determina stagnarea temporara a acceselor la memorie sau chiar a procesarii 


interne. La scriere, problema aceasta nu se pune datorita procesorului de iesire 


specializat DWB care lucreaza in paralel cu procesorul central dupa cum deja am 
aratat. 

5. Nivelul WB (write buffer) - se scrie rezultatul ALU sau data citita din 
memorie (in cazul unei instructiuni LOAD) in registrul destinatie din setul de 
registri generali ai microprocesorului. 

Prin urmare, printr-o astfel de procesare se urmareste o rata ideala de o 
instructiune / ciclu masina ca in figura 2.7, desi dupa cum se observa, timpul de 


executie pentru o instructiune data nu se reduce. 
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Figura 2.7. Principiul procesarii pipeline într-un procesor RISC 
Se observa imediat necesitatea suprapunerii a 2 nivele concurentiale: nivelul 
IF si respectiv nivelul MEM, ambele cu referire la memorie. În cazul 
microprocesoarelor RISC aceasta situatie se rezolva deseori prin legaturi (busuri) 
separate între procesor si memoria de date respectiv de instructiuni (arhitectura 


Harvard). 


Desi aceasta impartire pe 5 nivele este caracteristica mai multor 
microprocesoare RISC, ea are o deficienta importanta si anume ca nu orice 
instructiune trece prin toate cele 5 nivele de procesare. Astfel, nivelul MEM este 
exploatat doar de catre instructiunile LOAD / STORE, nivelul ALU de catre 
instructiunile aritmetico-logice si LOAD / STORE, iar instructiunile de comparare 
sau memorare (STORE) nu folosesc nivelul WB. Probabil asemenea observatii au 
determinat proiectantii anumitor microprocesore RISC (de ex. microprocesorul 
HARP - Hatfield Advanced RISC Processor proiectat la Universitatea din 
Hertfordshire, Marea Britanie), sa comprime nivelele ALU si MEM într-unul 
singur. In acest caz calculul adreselor de memorie se face in nivelul RD pin 
mecanisme care reduc acest timp de calcul [Ste91]. 

În literatura se citeaza un model de procesor numit superpipeline. Acesta 
este caracterizat printr-un numar relativ mare al nivelelor de procesare. Desigur ca 
în acest caz detectia si corectia hazardurilor este mai dificila, dupa cum se va arata 
în continuare. Arhitecturile superpipeline se preteaza la tehnologiile cu grade de 
împachetare reduse unde nu este posibila multiplicarea resurselor hardware, în 
schimb caracterizate prin viteze de comutatie ridicate (ECL, GaAs). O asemenea 
arhitectura caracterizeaza de ex. procesoarele din familia DEC (Digital Equipment 
Corporation) Alpha. Avantajul principal al arhitecturilor superpipeline este ca 
permit frecvente de tact deosebit de ridicate (500-800 MHz la nivelul tehnologiilor 


actuale), aspect normal având în vedere super - divizarea stagiilor de procesare. 


2.4.3. STRUCTURA PRINCIPIALA A UNUI PROCESOR RISC 


În continuare se prezinta o structura hardware de principiu a unui procesor 
RISC compatibil cu modelul Œ programare al microprocesorului RISC Berkeley I 
anterior prezentat. De remarcat ca structura permite procesarea pipeline a 
instructiunilor, adica atunci când o instructiune se afla într-un anumit nivel de 
procesare, instructiunea urmatoare se afla în nivelul anterior. Stagiile de 
interconectare ale nivelelor structurii (IF / ID, ID / EX, EX / MEM, MEM / WB) 
sunt implementate sub forma unor registri de încarcare, actualizati sincron cu 
fiecare nou ciclu de procesare. Memorarea anumitor informatii de la un nivel la 
altul este absolut necesara, pentru ca informatiile continute în formatul instructiunii 
curente sa nu se piarda prin suprapunerea fazelor de procesare. 

În acest sens, sa ne imaginam de exemplu ce sar întâmpla daca câmpul 
DEST nu ar fi memorat succesiv din nivel în nivel si rebuclat la intrarea setului de 
registri generali (vezi Fig.2.8). Utilitatea acestui câmp devine oportuna abia în faza 
WB când si data de înscris în setul de registri generali devine disponibila (cazul 
instructiunilor aritmetic o-logice sau STORE). Sa remarcam ca setul de registri 
generali trebuie sa permita simultan doua citiri si o scriere. 

Multiplexorul de la intrarea ALU are rolul de a genera registrul sursa 2, în 
cazul instructiunilor aritmetico-logice, respectiv indexul de calcul adresa (constanta 


pe 13 biti cu extensie semn), în cazul instructiunilor LOAD / STORE. Sumatorul 


SUM 2 calculeaza adresa de salt in cazul instructiunilor de salt (branch) dupa 
formula: 


PCnext = PC + Ext.semn(IR18 - 0) (2.3.) 


Adresă de salt 


Figura 2.8. Schema de principiu a unui procesor RISC 


Multiplexorul 2:1 de la iesirea nivelului MEM / WB multiplexeaza rezultatul 
ALU in cazul unei instructiuni aritmetico-logice, respectiv data citita din memoria 
de date in cazul unei instructiuni LOAD. Iesirea acestui multiplexor se va inscrie in 
registrul destinatie codificat in instructiune. Evident ca intreaga structura este 
comandata de catre o unitate de control. Detalii despre proiectarea unei asemenea 


unitati sunt date de exemplu in [Pat94], cap.6. 


2.4.4. PROBLEMA HAZARDURILOR IN PROCESOARELE RISC 


Hazardurile constituie acele situatii care pot sa apara in procesarea pipeline 
si care pot determina blocarea (stagnarea) procesarii, având deci o influenta 
negativa asupra ratei de executie a instructiunilor. Conform unei clasificari 
consacrate aceste hazarduri sunt de 3 categorii : hazarduri structurale, de date si 


de ramificatie. 


2.4.4.1. HAZARDURI STRUCTURALE (HS): PROBLEME IMPLICATE SI 
SOLUTII 


Sunt determinate de conflictele la resurse comune, adica atunci când mai 
multe procese simultane aferente mai multor instructiuni în curs de procesare, 
acceseaza o resursa comuna. Pentru a le elimina prin hardware, se impune de 
obicei multiplicarea acestor resurse. De exemplu, un procesor care are un set de 
registri generali de tip uniport si în anumite situatii exista posibilitatea ca 2 procese 
sa doreasca sa scrie in acest set simultan. Prezentam mai jos (Fig.2.9) o structura 
ALU implementata la microprocesorul RISC superscalar HARP care permite 4 
operatii ALU simultane. Prin partitionarea timpului afectat nivelului WB în doua, 
în cadrul acestui nivel se pot face doua scrieri (în prima jumatate a nivelului WB se 
înscrie în setul de registri continutul caii A, iar în a doua parte a nivelului WB se 
înscrie continutul caii B). În principiu, un astfel de procesor poate sa execute 4 


instructiuni simultan cu conditia ca numai doua dintre ele sa aiba nivelul WB activ. 


Evident ca cele 4 seturi de registri generali detin continuturi identice în orice 
moment. Deci, prin multiplicarea resurselor hardware s-a creat posibilitatea 
executiei mai multor operatii (instructiuni) fara a avea conflicte la 
resurse[Ste92,93,95]. 

O alta situatie de acest fel, dupa cum deja am mai aratat, poate consta in 
accesul simultan la memorie a 2 procese distincte: unul de aducere a instructiunii 
(IF), iar celalalt de aducere a operandului sau scriere a rezultatului in cazul unei 
instructiuni LOAD / STORE (nivelul MEM). Dupa cum am mai aratat, aceasta 
situatie se rezolva in general pintr-o arhitectura Harvard a busurilor si cache- 
urilor. Totusi, exista microprocesoare care detin busuri si cache-uri unificate pe 
instructiuni si date (Power PC 601, de exemplu). O cercetare detaliata a acestei 
probleme, practic nedezbatuta in literatura de specialitate, va constitui obiectul unei 


investigatii speciale a prezentei lucrari (Cap. 4, 5). 


SET SET 
REGISTRE REGISTRE 


Figura 2.9. Structura de procesare multipla. 
Sa consideram acum, fara a reduce din generalitate, o structura pipeline cu 5 


nivele având timpul de"setup" de 7 cicli, descrisa în functionare de tabelul 2.1. 


Tabelul 2.1. Descrierea functionarii unei structuri pipeline cu 5 nivele 


Un X in tabel semnifica faptul ca in ciclul Ti nivelul Nj este activ adica 
proceseaza informatii. Sa mai consideram ca aceasta structura pipeline corespunde 
unui anumit proces (de ex. procesarea unei instructiuni). Se observa ca un alt 
proces de acest tip, nu poate starta in ciclul urmator (T2) datorita coliziunilor care 
ar putea sa apara între cele doua procese pe nivelul (N2, T3) si respectiv (N3, T4). 
Mai mult, urmatorul proces n-ar putea starta nici macar in T3 din motive similare 
de coliziune cu procesul anterior în nivelul (N4, T5). În schimb procesul urmator ar 
putea starta în T4 fara a produce coliziuni sau hazarduri structurale cum le-am 
denumit, deci la 2 cicli dupa startarea procesului curent. 

Se defineste vectorul de coliziune al unei structuri pipeline având timpul de 
setup de (N+1) cicli, un vector binar pe N biti astfel: daca bitul i, i€ (0, 1, ..., N-1} 
e | logic atunci procesul urmator nu poate fi startat dupa i cicli de la startarea 
procesului curent, iar daca bitul i este 0 logic, atunci procesul urmator poate fi 
startat dupa i cicli fara a produce coliziuni cu procesul curent. Se observa de 
exemplu pentru structura pipeline anterioara ca vectorul de coliziune este 110000, 
însemnând deci ca procesul urmator nu trebuie startat în momentele T2 sau T3, in 
schimb poate fi startat fara probleme oricând dupa aceea. 

Se pune problema: cum trebuie gestionata o structura pipeline data, 
caracterizata printr-un anumit vector de coliziune, asftel încât sa se obtina o rata de 


procesare (procese / ciclu) maxima ? Considerând o structura pipeline cu timpul de 


"setup" de 8 cicli si având vectorul de coliziune 1001011 ar trebui procedat ca în 


figurile urmatoare (Fig. 2.10, 2.11): 


după 2 cicli, startare proces următor 


0101100¥ 
1001011 SAU LOGIC 
1101111 


după 3 cicli, startare proces următor 


1111000¥ 
1001011 


1111011 


dupa 5 cicli, urmatorul 


Figura 2.10 Principiul de lansare procese într-o structura pipe cu hazarduri structurale 


EERE | 
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Figura 2.11. Graful de optimizare intr-o structura pipeline 


Vectorul unei stari Sj, se obtine dupa relatia: 


Vj = (VC) V (Vi'(m)) , (2.4) 
V = SAU logic 
VC = vector coliziune 


Vi (m) = vectorul Vi deplasat logic la stânga cu (m) pozitii binare 


Figura 2.12. Trecerea dintr-o stare în alta 

Pentru maximizarea performantei, se pune problema ca pornind din starea 
initiala a grafului, sa se determine un drum închis în graf cu proprietatea ca NS / L 
sa fie maxim, unde NS = numarul de stari al drumului iar L = lungimea drumului. 
În cazul anterior considerat, avem L = 3 + 5 + 3 + 2 = 13, iar NS = 4. Printr-o astfel 
de gestionare a structurii se evita coliziunile si se obtine o performanta optima de 4 
procese în 13 cicli, adica 0.31 procese / ciclu. De mentionat ca o structura 
conventionala ar procesa doar 0.125 procese / ciclu. Nu întotdeauna sartarea 
procesului urmator imediat ce acest lucru devine posibil ("greedy strategy"), duce 


la o performanta maxima. Un exemplu în acest sens ar fi o structura pipeline cu 


vectorul de coliziune asociat 01011. E adevarat însa ca o asemenea strategie 
conduce la dezvoltarea unui algoritm mai simplu. 

Este clar ca performanta maxima a unei structuri pipeline se obtine numai în 
ipoteza alimentarii ritmice cu date de intrare. În caz contrar, gestiunea structurii se 
va face pe un drum diferit de cel optim în graful vectorilor de coliziune. În [Sto93] 
paginile 182 - 190, se arata pe baza unei tehnici elementare atribuita lui Patel si 
Davidson (1976), ca prin modificarea tabelei aferenta structurii pipeline în sensul 
introducerii unor întârzieri, se poate îmbunatati performanta benzii. 

Sa consideram acum o structura pipeline bifunctionala capabila sa execute 2 
tipuri de procese: P1 si respectiv P2. Aceste procese sunt descrise prin tabele 
adecvate, în care se arata ce nivele solicita procesul în fiecare ciclu. Este clar ca 
aceste procese vor fi mai dificil de controlat. Pentru controlul acestora prin 
structura, este necesar a fi determinati mai întâi vectorii de coliziune si anume: 
VC(PI, P1) , VC(P1, P2), VC(P2, P1) si VC(P2, P2), unde prin VC(Pi, Pj) am 
notat vectorul de coliziune între procesul curent Pi si procesul urmator Pj. Odata 
determinati acesti vectori în baza tabelelor de descriere aferente celor doua procese 
controlul structurii s-ar putea face prin schema de principiu din figura 2.13. 

Initial registrul "P1 control" contine VC(PI, P1), iar registrul "P2 control" 
contine VC(P2, P2). Procesul urmator care se doreste a fi startat în structura va face 
o cerere de startare catre unitatea de control. Cererea va fi acceptata sau respinsa 


dupa cum bitul cel mai semnificativ al registrului de control este 0 sau 1 respectiv. 


Dupa fiecare iteratie, registrul de control se va deplasa logic cu o pozitie la stânga 
dupa care se executa un SAU logic între continutul registrului de control, caile (A) 
si (B) respectic caile de date (C) si (D), cu înscrierea rezultatului în registrul de 
control. Se observa în acest caz ca gestionarea proceselor se face dupa o strategie 


de tip "greedy". 


¥C [ P1, P1) VC [ P1, P2) 


P2 acceptat 
[dacă e 0) 


(0) 


P1 acceptat P2 acceptat 


Figura 2.13. Controlul unei structuri pipeline bifunctionale 


2.4.4.2. HAZARDURI DE DATE: DEFINIRE, CLASIFICARE, SOLUTII DE 
EVITARE A EFECTELOR DEFAVORABILE 


Apar când o instructiune depinde de rezultatele unei instructiuni anterioare în 
banda. Pot fi la rândul lor clasificate în 3 categorii, dependent de ordinea acceselor 


de citire respectiv scriere, în cadrul instructiunilor. 


Considerând instructiunile i si j succesive, hazardul RAW (Read After 
Write) apare atunci când instructiunea j încearca sa citeasca o sursa înainte ca 
instrucțiunea i sa scrie în aceasta. Apare deosebit de frecvent in implementarile 
actuale de procesoare pipeline. Sa consideram secventa de instructiuni de mai jos 
procesata într-o structura pe 5 nivele, ca în figura urmatoare. Se observa ca data ce 
urmeaza a fi incarcata in RS este disponibila doar la finele nivelului MEM aferent 
instructiunii I1, prea târziu pentru procesarea corecta a instructiunii 12 care ar avea 
nevoie de aceasta data cel târziu la începutul nivelului sau ALU. Asadar, pentru o 


procesare corecta, [2 trebuie stagnata cu un ciclu masina. 


LDS =2 
| ll 
| IF | RD | ALU | MEM f- WB | 
12: ADD R4,R5,R6 I2: IF ARD | 
13: data IF | RD | ALU | MEM] WB] 


necesara 


Fi e [Ro atu [MEM] we] 


data disponibila 


11: LD R5,Mem 11; (Load): 


Figura 2.14. Hazard RAW în cazul unei instructiuni LOAD 
Aceasta se poate realiza prin software, de exemplu prin inserarea unei 
instructiuni NOP între I1 si I2 (umplerea "load delay slot'-ului - LDS) sau o alta 
instructiune utila independenta de instructiunea I1. O alta modalitate de rezolvare 
consta in stagnarea hardware a instructiunii I2, stagnare determinata de detectia 


hazardului RAW de catre unitatea de control. Realizarea intarzierii hardware se 


poate baza pe tehnica "scoreboarding" propusa pentru prima data de catre Seymour 
Cray (1964 - CDC 6600). Se impune ca fiecare registru al procesorului din setul de 
registri sa aiba un "bit de scor" asociat. Daca bitul este zero, registrul respectiv e 
disponibil, daca bitul este 1, registrul respectiv este ocupat. Daca pe un anumit 
nivel al procesarii este necesar accesul la un anumit registru avand bitul de scor 
asociat pe 1, respectivul nivel va fi întârziat, permitându-i-se accesul doar cand 
bitul respectiv a fost sters de catre procesul care La setat (fig.2.15a, fig.2.15.b). De 
remarcat ca ambele solutii bazate pe stagnarea fluxului (software - NOP sau 


hardware - semafoare) au acelasi efect defavorabil asupra performantei. 


[elope] «= ide 
R2 

epope] He 

testare si setare bit scor a R5 


LD R5, Mem 


ADD R4, R5, R6 : 


Figura 2.15a. Detectie hazard pe baza bitului de scor 


LDR5,Mem_— : | jm 
CALs a i 


ADD R4, R5, R6 : 


LIF pp 


restartare 
procesare 


Figura 2.15b. Restartarea procesarii instructiunilor 


Exista situatii in care hazardul RAW se rezolva prin hardware fara sa cauzeze 
stagnari ale fluxului de procesare ca in cazul anterior. Aceste tehnici de rezolvare 
se numesc tehnici forwarding (bypassing) bazate pe "pasarea anticipata” a 
rezultatului instructiuni i, nivelului de procesare aferent instructiunii j care are 
nevoie de acest rezultat. De exemplu sa consideram secventa: 

ADD R1, R2, R3 ; R1 <------ (R2)+(R3) 


SUB R4, R1, R5 ; R4 <------ (R1)-(R5) 


ADD: IF RD ALU MEM WB { R1) 


R2 


SUB: IF RD ALU MEM WB (RA) 


READ reg 2 WRITE reg 


SET 
READ reg 1 REGISTRII GEN. 
data in 
data out 1 data out 2 


Tampoane 
ALU 
(R2)+(R3) 


Figura 2.16. Implementarea "forwarding" -ului 


Rezultatul ALU aferent primei instructii (R2 + R3) este memorat in 
tampoanele ALU la finele fazei ALU a instructiunii ADD. Daca unitatea de control 
va detecta hazardul RAW, va selecta pe parcursul fazei ALU aferente instructiunii 
SUB la intrarea A a ALU, tamponul care contine (R2) + (R3) (in urma fazei ALU a 
instructiunii ADD), evitând astfel hazardul RAW. Desigur, este necesara 
implementarea proceselor de forwarding nu numai de la iesirile ALU spre intrari ci 
si din cadrul nivelelor urmatoare (de ex. nivelul MEM) spre intrarile ALU. Aceasta 
situatie corespunde unor instructiuni dependente RAW dar nesuccesive strict în 
program. Valoarea "pasata" uneia din intrarile ALU in acest caz, reprezinta 
rezultatul ALU memorat în nivelul urmator (MEM) în cazul unor instructiuni 
aritmetico- logice sau data citita din memoria cache de date în cazul unor 
instructiuni LOAD. 

În implementarea controlului mecanismelor de forwarding, pot apare si 
situatii conflictuale care trebuiesc rezolvate pe baza de arbitrare-prioritizare. Ca 
exemplu în acest sens se considera secventa de instructiuni: 

Il: SUB R2,R1,R3 
12: AND  R2,R2,R5 
B: ADD  R6,R2,R4 
În acest caz se observa imediat ca apar necesare doua "pasari anticipate" de 


valori: de la I1 la I3 (R2) pe intrarea A a ALU si respectiv de la I2 la I3 (R2) pe 


aceeasi intrare A a ALU. Este evident ca in acest caz trebuie acordata prioritate 
nivelului pipeline mai "apropiat" de ALU, deci informatiei produsa de iesirile ALU 
si nu celei situate în nivelul urmator (MEM aici). Cu alte cuvinte, se preia pe 
intrarea A a ALU rezultatul produs de I2 si nu cel produs de I1. Rezulta deci ca si 
astfel de potentiale situatii conflictuale trebuie implementate în logica de control a 
mecanismelor de forwarding. 

Hazardul WAR (Write After Read) poate sa apara atunci când instructiunea 
j scrie o destinatie înainte ca aceasta sa fie citita pe post de sursa de catre o 
instructiune anterioara notata i. Poate sa apara când într-o structura pipeline exista 
o faza de citire posterioara unei faze de scriere. De exemplu, modurile de adresare 
indirecta cu predecrementare pot introduce acest hazard, de aceea ele nici nu sunt 


implementate în arhitecturile de tip RISC. 


-1R RD R 


(WR) 


(WR) 


Figura 2.17. Aparitia unui hazard WAR 
De precizat ca aceste hazarduri WAR (Write After Read), pot apare si 
datorita executiei instructiunilor în afara ordinii lor normale, din program (executie 
Out of Order), dupa cum se va remarca în continuare. Aceasta procesare Out of 


Order este impusa de cresterea performantei si se poate realiza atât prin mijloace 


hardware cat si software, legat de optimizarea programelor pe arhitecturile 
pipeline. 

Hazardul WAW (Write After Write), apare atunci cand instructiunea j scrie 
un operand înainte ca acesta sa fie scris de catre instructiunea i. Asadar, în acest 
caz scrierile s-ar face într-o ordine eronata. Hazardul WAW poate aparea în 
structurile care au mai multe nivele de scriere sau care permit unei instructiuni sa 
fie procesata chiar daca o instructiune anterioara este blocata. Modurile de adresare 
indirecta cu postincrementare pot introduce acest hazard, fapt pentru care ele sunt 
evitate în procesoarele RISC. De asemenea, acest hazard poate sa apara in cazul 


executiei Out of Order a instructiunilor care au aceeasi destinatie. 


WR Ri #1 Rj 


(WR) 
WAR 


WR Ri +1 Rk 


Figura 2.18 Aparitia unui unui hazard WAW 


Hazardurile de tip WAW sau WAR nu reprezinta hazarduri reale, ci mai 
degraba conflicte de nume. Ele pot fi eliminate de catre compilator (scheduler) prin 
redenumirea resurselor utilizate de program. De aceea se mai numesc dependente 
de iesire respectiv antidependente. 

Ex.: Il: MULF Ri, Rj, Rk; Ri <--- (Rj ) * (Rk) 


I2: ADD Rj, Rp, Rm; Rj <-- (Rp) + (Rm) 


În acest caz poate sa apara hazard WAR întrucât instructiunea I1 fiind o 
instructiune de coprocesor flotant se va încheia în executie dupa I2 care este o 
instructiune de procesor cu operanzi întregi. Am presupus deci ca numarul de 
nivele aferent structurii pipeline a coprocesorului este mai mare decât numarul de 
nivele aferent procesorului. Rezulta deci ca instructiunile I1, I2 se termina "Out of 
Order" (I2 înaintea lui 11). Secventa reorganizata prin software, care elimina 
hazardul WAR este : 

MULF Ri, Rj, Rk 
ADD Rx, Rp, Rm 
MOV RJ, Rx : Rj < Rx (dupa Ri <- (Rj) x (Rk)) 
Prezentam in continuare un exemplu de reorganizare a unui program in 
vederea eliminarii hazardurilor de date si a procesarii sale optimale: 
10 ADD R3, R1, R2 
I1 LD R9, A(R7) 
I2 ADD R4, R3, R2 
13 ADD R5, R4, R6 
14 LD R4, A(R6) 
I5 LD R2, A(R4) 
Graful dependentelor de date corespunzator acestei secvente este urmatorul 


(vezi Fig.2.19): 


Figura 2.19. Graful dependentelor de date asociat secventei 

Aparent, pe baza grafului de mai sus, secventa reorganizata ar starta astfel: 

10 ADD R3, R1, R2 
Il LD RS, A(R7) 

14 LD R4, A(R6) 

12 ADD R4, R3, R2 

13 ADD R5,R4,R6, etc. 

Se observa in acest caz ca executia Out of Order a instructiunilor I4 si I2 
determina o procesare eronata a programului prin hazardul de tip WAW prin 
registrul R4. De asemenea, între instructiunile I3 si I4 exista hazard WAR prin 
acelasi registru. Asadar detectia hazardului WAW între instructiunile I2 si 14 
determina impunerea unei relatii de precedenta între aceste instructiuni, adica 
procesarea lor trebuie sa se realizeze în ordinea din program (In Order). În cazul 
nostru, este necesar deci ca I3, dependenta RAW de I2, sa se execute înaintea 


instructiunii I4. Aceste restrictii au fost evidentiate pin linie punctata în graful 


dependentelor de date, anterior prezentat. Tinând cont de cele de mai sus, pe baza 


grafului dependentelor de date, secventa reorganizata corect va fi: 


10 ADD R3, R1, R2 
II LD R9, A(R7) 
2 ADD R4, R3, R2 
B ADD R5, R4, R6 
4 LD R4, A(R6) 


NOP; Compensare LDS! 

I5 LD R2, A(R4) 

Rata de procesare în acest caz este de 6/7 instr./tact, performanta superioara 
programului initial întrucât prin procesarea Out of Order, se evita la maximum 
dependentele de date între instructiuni. Hazardul WAR între I3 si I4 prin registrul 
R4 ar putea fi eliminat prin redenumirea registrului R4 în instructiunea I4. De 
asemenea, relatii suplimentare de precedenta între instructiuni impun într-un mod 
analog hazardurile de tip WAR (în ex. nostru între I3 si 14). Dupa cum am mai 
aratat, hazardurile WAR si WAW nu reprezinta conflicte reale, ci doar asa-zise 
conflicte de nume, ele nefiind considerate dependente adevarate. Considerând un 
procesor cu mai multi registri fizici decât cei logici, precedentele impuse de aceste 
hazarduri pot fi eliminate usor prin redenumirea registrilor logici cu cei fizici 
(register renaming). Principiul consta în existenta unei liste a registrilor activi, 


adica folositi momentan, si o alta a celor liberi (adica a celor nefolositi momentan). 


Fiecare schimbare a continutului unui registru logic prin program, se va face asupra 
unui registru fizic disponibil in lista registrilor liberi si care va fi trecut in lista 


registrilor activi. In acest caz secventa in discutie s-ar transforma in urmatoarea: 


10: ADD R3a, Rla, R2a 
II: LD R9a, A(R7a) 
12: ADD R4a, R3a, R2a 
B: ADD R5a, R4a, R6a 
14: LD R4b, A(R6a) 
15: LD R2b, A(R4b) 


În acest caz in optimizare nu ar mai avea importanta decât dependentele 
RAW, celelalte fiind eliminate. În baza grafului dependentelor de date procesarea 
optimala ar însemna în acest caz: 10, I1, I4, I2, I3, I5, etc. Sa observam ca 
deocamdata am prezentat exclusiv problema reorganizarii asa numitelor "basic - 
block"-uri sau unitati secventiale de program. Se numeste basic-block o secventa 
de instructiuni cuprinsa între doua instructiuni de ramificatie, care nu contine nici o 
instructiune de ramificatie si care nu contine nici o instructiune destinatie a unei 
instructiuni de ramificatie. 

Optimizarea programelor în basic - block-uri este rezolvata înca din perioada 
de pionierat a cercetarilor legate de microprogramare. Din pacate, prin 


concatenarea mai multor basic- block-uri optimizate nu se obtine un program 


optimizat. Se pune deci problema unei optimizari globale, a intregului program 


(vom reveni în capitolul urmator). 


2.4.4.3. HAZARDURI DE RAMIFICATIE (HR): PROBLEME IMPLICATE 
SI SOLUTII 


Pot fi generate de catre instructiunile de ramificatie (branch). Cauzeaza 
pierderi de perfomanta în general mai importante decât hazardurile structurale si de 
date. Efectele defavorabile ale instructiunilor de ramificatie pot fi reduse prin 
metode soft (reorganizarea programului sursa), sau prin metode hard care 
determina în avans daca saltul se va face sau nu (branch prediction) si cakuleaza în 
avans noul PC (program counter). Diverse statistici arata ca instructiunile de salt 
neconditionat au o frecventa între 2 - 8% din instructiunile unui program de uz 
general, iar cele de salt conditionat între 11 - 17%. S-a aratat ca salturile 
conditionate simple se fac cu o probabilitate de cca. 50%, loop-urile cu o 
probabilitate de cca. 90%, iar majoritatea salturilor orientate pe bit nu se fac 
[Mil89]. 

Considerând o structura pipeline pe 5 nivele si ca la finele nivelului RD 
adresa de salt este disponibila, efectul defavorabil al unei instructiuni de salt este 
sugerat în figura 2.20. Evident ca în alte structuri "branch delay slot'-ul (BDS) 


poate fi mai mare decât un singur ciclu. 


1 ciclu 


Branch delay slot (BDS) = 1 


Daca saltul se va face, atunci 11 se va executa in mod nedorit. 


Figura 2.20. Hazardul de ramificatie pe un procesor scalar 

O prima solutie pentru o procesare corecta, ar fi aceea de a dezvolta unitatea 
de control hardware în vederea detectarii prezentei saltului si de a întârzia 
procesarea instructiunilor urmatoare cu un numar de cicli egal cu latenta BDS-ului, 
pâna când adresa de salt devine disponibila. Solutia implica desigur reducerea 
performantelor. Acelasi efect Far avea si "umplerea" BDS-ului de catre scheduler 
cu instructiuni NOP în vederea întârzierii necesare. 

În continuare se vor prezenta succint principiile si tehnicile care stau la baza 
solutionarii prin software a ramificatiilor de program. Acestea se bazeaza pe 
reorganizarea secventei de instructiuni masina, astfel încât efectul defavorabil al 
salturilor sa fie eliminat. În continuare se va prezenta o astfel de strategie atribuita 
lui T. Gross si J. Hennessy si dezvoltata inca din perioada de pionierat a acestor 
cercetari (1982). Mai întâi se defineste o instructiune de salt situata la adresa b spre 
o instructiune situata la adresa 1, ca un salt întârziat de ordinul n, daca 


instructiunile situate la locatiile b, b + 1,..... , b + n sil sunt executate întotdeauna 


cand saltul se face. O prima solutie de optimizare ar fi aceea de mutare a 


"A 


instuctiunii de salt cu n instructiuni "în sus". Acest lucru e posibil doar atunci când 
nici una dintre precedentele n instructiuni nu afecteaza determinarea conditiilor de 
salt. În general, se poate muta instructiunea de salt cu doar k instructiuni "în sus" 
unde k reprezinta numarul maxim de instructiuni anterioare care nu afecteaza 
conditiile de salt, kE (0, n]. Cand acest lucru se întâmpla, se poate aplica succesiv 
o alta tehnica ce consta în duplicarea primelor (n - k) instructiuni plasate începând 
de la adresa destinatie a saltului, imediat dupa instructiunea de salt si modificarea 


corespunzatoare a adresei de salt la acea adresa care urmeaza imediat dupa cele (n - 


k) instructiuni "originale", ca în figura 2.21. 


BRANCH <cond> , ADR BRANCH <cond> , ADR_M 
k LĪ l instr [es instr. aditionale 
ADR: ADR 1 
= | => ER 
(n-k) instr. | instr. 
ADR 2 
| (n-k) instr. "originale" 

ADR M 


| => ADR M=ADR + 1+2(n-k] 


Figura 2.21. Solutionarea unui hazard de ramificatie prin duplicarea instructiunilor 
În cazul în care saltul conditionat nu se executa, este necesar ca nici una 
dintre cele (n - k) instructiuni aditionale sa nu afecteze executia urmatoarelor (| + n 
- k) instructiuni. Metoda se recomanda atunci cînd saltul se face predominant, ceea 


ce poate fi stabilit în urma colectarii unor statistici obtinute dupa rulare (profilings). 


În acest caz se realizeaza un câstig de performanta in schimb se suplimenteaza 
spatiul de memorare al programului. De remarcat ca aceste microprocesoare nu au 
în general registru de flaguri si deci salturile conditionate nu se fac pe baza acestor 
flaguri ci pe baza unei conditii specificate explicit în opcode-ul instructiunii de salt. 

În continuare se prezinta un exemplu concret de reorganizare în vederea 
eliminarii efectului BDS- ului, considerând însa ca BDS- ul instructiunii de salt 
este doar de 1 tact. 

a) 


ADD R1, R2, R3 if (R2 = 0) then 


if (R2 = 0) then ` ADD Al, R2, R3 | 


BDS! 


Figura 2.22. Solutionarea optima 


Strategia anterioara îmbunatateste rata de executie întotdeauna, indiferent 
daca saltul se face ori nu se face. Daca aceasta reorganizare nu e posibila, se 
încearca una dintre urmatoarele 2 variante ((b) sau (c)). 


b) 


ADD R1, R2, R3 
if (R1 = 0) then 


ADD R1, R2, R3 
if (R1 = 0) then 


SUB R4, R5, R6 | 


BDS! 


SUB R4, R5, R6 


Figura 2.23. Solutie utila când saltul se face preponderent 


In acest caz, rata de executie creste doar atunci cînd saltul conditionat se face. 


Daca saltul nu se face, trebuie ca instructiunea introdusa în BDS (SUB R4, R5, 


R6), sa nu provoace executia eronata a ramurii de program respective. Din pacate 


un astfel de caz mareste zona de cod oricum si în plus necesita timp de executie 


sporit cu o instructiune aditionala în cazul în care saltul nu se face. 


c) 


ADD R1, R2, R3 
if (R1) = 0 then 


XOR R7, R8, RI 


ADR : 


ADD R1, R2, R3 
if (R1 = 0) then 


XOR R7, R8, R9 | 


BDS 


(ADR - 1): 


Figura 2.24. Solutie utila cand saltul nu se face preponderent 


Acest ultim caz, creste performanta doar atunci cand saltul conditionat nu se 
face. Si aici este necesar ca instructiunea introdusa în BDS, sa nu provoace 
executia eronata a ramurii de program in cazul in care saltul se face. 

În concluzie, prin toate aceste strategii software se urmareste "umplerea" 
BDS-ului cu instructiuni utile si care sa nu afecteze programul din punct de vedere 
logic. În general microprocesoarele RISC, care detin un BDS de una-doua 
instructiuni, au posibilitatea - printr-un bit din codul instructiunii de salt conditionat 
- sa introduca stagnari hardware în cazul salturilor conditionate sau sa se bazeze pe 
umplerea BDS-ului cu instructiuni NOP sau cu alte instructiuni utile de catre 
reorganizator (scheduler). 

În cele ce urmeaza, se vor prezenta pe larg, într-un mod critic si pe deplin 
actualizat, cele mai performante strategii actuale de gestionare a ramificatiilor de 
program si anume predictia prin hardware. Aceste strategii hardware de predictie a 
branch-urilor au la baza un proces de predictie "run - time" a ramurii de salt 
conditionat precum si determinarea în avans a noului PC. Ele sunt comune practic 
atât procesoarelor scalare cât si celor cu executii multiple ale instructiunilor care se 
vor analiza în detaliu în capitolul urmator al acestei lucrari. Cercetari recente 
insista pe aceasta problema, întrucât s-ar elimina necesitatea reorganizarilor soft ale 
programului sursa si deci s-ar obtine o independenta fata de masina. 

Necesitatea predictiei, mai ales în cazul procesoarelor cu executii multiple ale 


instructiunilor (VLIW, superscalare, etc., vezi cap. 3, 6) este imperios necesara. 


Notand cu BP (Branch Penalty) numarul mediu de cicli de asteptare pentru fiecare 
instructiune din program, introdusi de salturile fils predictionate, se poate scrie 
relatia: 

BP= C (1-Ap) b IR (2.5) 

unde s-au notat prin: 

C= Numarul de cicli de penalizare introdusi de un salt prost predictionat 

Ap= Acuratetea predictiei 

b= Procentajul instructiunilor de salt, din totalul instructiunilor, procesate in 
program 

IR= Rata medie de lansare in executie a instructiunilor 

Se observa ca BP(Ap=0)=C b IR, iar BP(Ap=1)=0 (normal, predictia este 
ideala aici). Impunând un BP=0.1 si considerând valorile tipice: C=5, IR=4, 
b=22.5%, rezulta ca fiind necesara o acuratete a predictiei de peste 97.7% ! Cu alte 
cuvinte, la o acuratete de 97.7%, IR=4/1.4=2.8 instr./ciclu, fata de IR=4 instr./ciclu, 
la o predictie perfecta (Ap=100%). Este o dovada clara ca sunt necesare acurateti 
ale predictiilor foarte apropiate de 100% pentru a nu se "simti" efectul defavorabil 
al ramificatiilor de program asupra performantei procesoarelor avansate. O metoda 
consacrata în acest sens o constituie metoda "branch prediction buffer" (BPB). 
BPB-ul reprezinta o mica memorie adresata cu cei mai putin semnificativi biti ai 
PC-ului aferent unei instructiuni de salt conditionat. Cuvântul BPB este constituit 


în principiu dintr-un singur bit. Daca acesta e 1 logic, atunci se prezice ca saltul se 


va face, iar daca e 0 logic, se prezice ca saltul nu se va face. Evident ca nu se poate 
sti in avans daca predictia este corecta. Oricum, structura va considera ca predictia 
este corecta si va declansa aducerea instructiunii urmatoare de pe ramura prezisa. 
Daca predictia se dovedeste a fi fost falsa structura pipeline se evacueaza si se va 
initia procesarea celeilale ramuri de program. Totodata, valoarea bitului de 
predictie din BPB se inverseaza. 

BPB cu un singur bit are un dezavantaj care se manifesta cu precadere in 
cazul buclelor de program ca cea din figura urmatoare, în care saltul se va face (N 
- 1) ori si o data, la iesirea din bucla nu se face. Bazat pe tehnica BPB în acest caz 
vom avea uzual 2 predictii false: una la intrarea în bucla (prima parcurgere) si alta 


la iesirea din bucla (ultima parcurgere a buclei). 


CN 
START: , 
I 
I 
CC) 


Figura 2.25. O bucla tipica 


Asadar, acuratetea predictiei va fi de (N - 2) * 100 / N %, iar saltul se face în 


proportie de (N - 1) * 100 / N %. Pentru a elimina acest dezavantaj se utilizeaza 2 


biti de predictie modificabili conform grafului de tranzitie de mai jos (numarator 
saturat). In acest caz acuratetea predictiei unei bucle care se face de (N - 1) ori va fi 


(N - 1) * 100/N %. 


Figura 2.26. Automat de predictie de tip numarator saturat pe 2 biti 


Prin urmare, in cazul in care se prezice ca branch-ul se va face, aducerea noii 
instructiuni se face de îndata ce continutul noului PC e cunoscut. În cazul unei 
predictii incorecte, se evacueaza structura pipeline si se ataca cealalta ramura a 
instructiunii de salt. Totodata, bitii de predictie se modifica în conformitate cu 
graful din figura numit si numarator saturat (vezi Fig.2.26). Probabilitatea p ca 
predictia sa fie corecta pentru o instructiune de salt, este data de relatia: 

p=pl * p2 + (-p2) * p3, (2.6) 

unde am notat prin: 

pl, p2 - probabilitatea ca predictia adresata in BPB sa fie corecta si sa se 


refere la respectiva instructiune de salt; 


(1-p2)*p3 - probabilitatea ca predictia sa fie corecta, desi nu se refera la 
instructiunea in curs de aducere. (Exista de ex. posibilitatea ca 2 instructiuni de 
branch distincte sa aiba cei mai putini semnificativi biti ai PC-ului identici). Este 
evident ca maximizarea probabilitatii P se obtine prin maximizarea probabilitatilor 
pl, p2 (p3 nu depinde de caracteristicile BPB-ului). 

Datorita faptului ca predictorul propriu-zis este implementat prin automate 
finite de stare, mai mult sau mai putin complexe, aceste scheme au un caracter 
dinamic, comportarea lor adaptându-se functie de “istoria” saltului respectiv. 
Exista si scheme de predictie numite statice, caracterizate prin faptul ca predictia 
saltului pentru o anumita istorie a sa este fixa, bazata în general pe studii statistice 
ale comportamentului salturilor. Astfel de exemplu un salt care anterioarele trei 
instante s-a facut efectiv (taken) poate fi predictionat în tabele ca se va face. 
Desigur ca cel putin principial, o schema dinamica de predictie este superioara 
uneia statice datorita adaptabilitatii sale. 

O alta problema delicata consta în faptul ca desi predictia poate fi corecta, de 
multe ori adresa de salt (noul PC) nu este disponibila în timp util, adica la finele 
fazei de aducere IF. Timpul necesar calculului noului PC are un efect defavorabil 
asupra ratei de procesare. Solutia la aceasta problema este data de metoda de 
predictie numita "branch target buffer” (BTB). Un BTB este constituit dintr-un 
BPB care contine pe lânga bitii de predictie, noul PC de dupa instructiunea de salt 


conditionat si eventual alte informatii. De exemplu, un cuvânt din BTB ar putea 


contine si instructiunea tinta a saltului. Astfel ar creste performanta, nemaifiind 
necesar un ciclu de aducere a acestei instructiuni, dar in schimb ar creste costurile 
de implementare. Diferenta esentiala intre memoriile BPB si BTB consta in faptul 
ca prima este 0 memorie operativa iar a 2-a poate fi asociativa, ca in figura 
urmatoare. 

La începutul fazei IF se declanseaza o cautare asociativa in BIB dupa 
continutul PC-ului în curs de aducere. În cazul în care se obtine hit se obtine în 
avans PC-ul aferent instructiunii urmatoare. Mai precis, considerând o structura 
pipeline pe 3 faze (IF, RD, EX) algoritmul de lucru cu BTB-ul este în principiu 


urmatorul [Hen96]: 


PC instr. de branch| Next PC (prezis) 


Memoria BTB 


NU [MISS]  Instructiunea nu e prezisa ca 
fiind una de salt. Procedeaza 
normal. 


DA (HIT) 
instructiune de salt. PC-ul prezis va fi 


folosit ca next PC. 


Figura 2.27. Structura de predictie BTB asociativa 


IF) Se trimite PC-ul instructiunii ce urmeaza a fi adusa spre memorie si spre 
BTB. Daca PC-ul trimis corespunde cu un PC din BTB (hit) se trece în pasul RD2, 
altfel in pasul RD1. 

RD1) Daca instructiunea adusa e o instructiune de branch, se trece in pasul 
EX1, altfel se continua procesarea normala. 

RD2) Se trimite PC-ul prezis din BTB spre memoria de instructiuni. În cazul 
în care conditiile de salt sunt satisfacute, se trece în pasul EX 3, altfel în pasul EX2. 

EX1) Se introduce PC-ul instructiunii de salt precum si PC-ul prezis în BTB. 
De obicei aceasta alocare se face în locatia cea mai de demult neaccesata (Least 
Recently Used - LRU). 

EX2) Predictia s-a dovedit eronata. Trebuie reluata faza IF de pe cealalta 
ramura cu penalizarile de rigoare datorate evacuarii structurilor pipeline. 

EX3) Predictia a fost corecta, însa numai daca si PC-ul predictionat este într- 
adevar corect, adica neschimbat. În acest caz, se continua executia normala. 

În tabelul urmator (tabelul 2.2) sunt rezumate avantajele si dezavantajele 


tehnicii BTB, anterior descrise. 


Tabelul 2.2. Penalizarea într-o structura de predictie tip BTB 


Instr. în BTB ? Cicli penalizare 
(N ee as. 


In baza celor anterior discutate, rezulta ca numarul de cicli de penalizare CP 
este dat de urmatoarea relatie: 
CP = PBTB (Ptn*Cin +Pat*Cnt) +(-PBTB )*P*Ct (2.7) 
unde s-a notat: 


PpTp - probabilitatea ca instructiunea de salt sa se afle în BTB; 


Pin  - probabilitatea ca saltul sa fie prezis ca se face si în realitate nu se va 
face; 

Ppt  - probabilitatea ca saltul sa fie prezis ca nu se face si în realitate se va 
face; 

P - probabilitatea ca respectiva instructiune de salt sa se faca; 


Aceasta relatie, justificata în [Hen96], necesita amendamente serioase pentru 
a fi utila si exacta, dupa cum se va arata într-o contributie ulterioara a acestei 
lucrari. In acest caz, rata de procesare a instructiunilor ar fi data de relatia: 


IR= 1/(1 + PpxCP), [instr./tact], (2.8) 
unde Pp= probabilitatea ca instructiunea curenta sa fie una de ramificatie. 


Un model matematic simplu al acestei tehnici pentru un BTB cu N biti de 


memorare, legat de eficienta schemei, se refera la maximizarea functiei [Per93]: 


F=} Pox(i)[PG*Pyl*V@ - (1 - PO) Pini WO] (2.9) 


i=l 


astfel încât y n(i) <N, 


i=l 
unde : 
n( i ) - numarul de biti din BIB alocat instructiunii de branch i; 
N -numarul total de biti din BTB; 
S  - numarul de instructiuni branch procesate în cadrul programului; 
Relativ la expresia functiei F avem urmatorii termeni: 


Pex(1 ) - probabilitatea ca branch-ul i sa se execute în cadrul programului ; 


P(i) - probabilitatea ca branch-ul i sa se faca; 

Pu(i ) - probabilitatea ca branch-ul i sa fie prezis ca se face si într-adevar se 
va face; 

V(i) - numarul de cicli economisiti în cazul unei predictii corecte a branch- 
ului i; 

W( i ) - numarul de cicli de penalizare în cazul unei predictii incorecte a 
branch-ului 1; 

Obs.1) Py(i ) = Pin(i ) = 0, daca branch-ul i nu se afla în BTB. 

Obs.2) S-a considerat ca BTB nu îmbunatateste performanta pentru o 


predictie corecta de tipul "saltul nu se face" (Phn( i ) = 0), întrucât în acest caz 


structura se comporta în mod implict la fel ca si o structura fara BTB. De 


asemenea, pentru o predictie incorecta a faptului ca "saltul se face", am considerat 


costul acelasi cu cel pe care l-am avea fara BTB; din acest motiv Ppt( i ) nu intra în 


expresia functiei. 

Obs.3) Un branch trebuie introdus în BTB, cu prima ocazie când el se va 
face. Un salt care ar fi prezis ca nu se va face nu trebuie introdus în BTB pentru ca 
nu are potentialul de a imbunatati performanta (nu intra în expresia functiei F). Din 
acest motiv, exista strategii care atunci când trebuie evacuat un branch din BTB îl 
evacueaza pe cel cu potentialul de performanta minim, care nu coincide neaparat 
cu cel mai putin folosit (vezi [Dub91, Per93]). Astfel în [Per93] se construieste câte 
o variabila MPP (Minimum Performance Potential), implementata în hardware, 
asociata fiecarui cuvânt din BIB. Evacuarea din BTB se face pe baza MPP-ului 
minim. Acesta se calculeaza ca un produs între probabilitatea ca un branch din 
BTB sa fie din nou accesat (LRU) si respectiv probabilitatea ca saltul sa se faca. 
Aceasta din urma se obtine pe baza unei istorii a respectivului salt (taken / not 
taken). Minimizarea ambilor factori duce la minimizarea MPP-ului si deci la 
evacuarea respectivului branch din BTB, pe motiv ca potentialul sau de 
performanta este minim. 

În literatura se arata ca prin astfel de scheme se ajunge la predictii corecte în 
cca. (80-90)% din cazuri. Exista implementari de mare performanta în care bitii de 
predictie sunt gestionati si functie de "istoria" respectivei instructiuni de salt, pe 


baze statistice (INTEL NEX GEN, TRON, etc). Prin asemenea implementari creste 


probabilitatea de predictie corecta a branch-ului. Microprocesorul Intel Pentium 
avea un predictor de ramificatii bazat pe un BTB cu 256 de intrari. 

O problema dificila este determinata de instructiunile de tip RETURN 
întrucât o aceeasi instructiune, poate avea adrese de revenire diferite, ceea ce va 
conduce în mod normal la predictii eronate, pe motivul modificarii adresei eronate 
în tabela de predictii. Desigur, problema se pune atât în cazul schemelor de tip 
BTB cât si a celor de tip corelat, ce vor fi prezentate în continuare. Solutia de 
principiu [Kae91], consta în implementarea în hardware a unor asa zise "stack - 
frame"- uri diferite. Acestea vor fi niste stive, care vor contine perechi CALL/ 
RETURN cu toate informatiile necesare asocierii lor corecte. Astfel, o instructiune 
CALL poate modifica dinamic în tabela de predictii adresa de revenire pentru 
instructiunea RETURN corespunzatoare, evitându-se astfel situatiile nedorite mai 
sus schitate. 

În literatura [Hen96, Dub91, Per93], bazat pe testari laborioase, se arata ca se 
obtin predictii corecte în cca. 88% din cazuri folosind un bit de predictie si 
respectiv în cca.93% din cazuri folosind 16 biti de predictie. Acuratetea predictiilor 
creste asimptotic cu numarul bitilor de predictie utilizati, adica practic cu "istoria 


predictiei". Schema de predictie pe 4 stari din figura 3.27 poate fi generalizata usor 


la N = 2K stari. Se poate arata ca exista N2N * 2N (stari x iesiri) automate distincte 
de predictie cu N stari, desi multe dintre acestea sunt triviale din punct de vedere al 


predictiilor salturilor. În [Nai95] se arata într-un mod elegant, pe baza teoretica si 


de simulare, ca schema din fig. 2.26 este cvasioptimala in multimea acestor 
automate de predictie. In acord cu literatura de specialitate, marirea numarului N de 
stari al automatului de predictie pe k biti nu conduce la cresteri semnificative ale 
performantei. Dupa cum vom arata in continuare, prin scheme de predictie corelata 
a salturilor se pot obtine performante superioare. 

Schemele de predictie anterior prezentate se bazau pe comportarea recenta a 
unei instructiuni de salt, de aici predictionându-se comportarea viitoare a acelei 
instructiuni de salt. Este posibila îmbunatatirea acuratetii predictiei daca aceasta se 
va baza pe comportarea recenta a altor instructiuni de salt, întrucât frecvent aceste 
instructiuni pot avea o comportare corelata în cadrul programului. Schemele bazate 
pe aceasta observatie se numesc scheme de predictie corelata si au fost introduse 
pentru prima data în 1992 în mod independent de catre Yeh si Patt si respectiv de 
Pan [Hen96, Yeh92, Pan92]. Sa consideram pentru o prima exemplificare a acestei 
idei o secventa de program C extrasa din benchmark-ul Eqntott din cadrul grupului 


de benchmark-uri SPECint '92: 


bl) if(x==2) 


O) if(y==2) 


63) if(k!=y) { 


Se observa imediat ca in acest caz daca salturile bl si b2 nu se vor face atunci 
saltul b3 se va face în mod sigur (x = y = 0). Asadar saltul b3 nu depinde de 
comportamentul sau anterior ci de comportamentul anterior al salturilor bl si b2, 
fiind deci corelat cu acestea. Evident ca în acest caz schemele de predictie anterior 
prezentate nu vor da randament. Daca doua branch-uri sunt corelate, cunoscând 
comportarea primului se poate anticipa comportarea celui de al doilea, ca în 
exemplul de mai jos: 


if (cond1) 


if (condl AND cond2) 

Se poate observa ca functia conditionala a celui de al doilea salt este 
dependenta de cea a primului. Astfel, daca prima ramificatie nu se face atunci se va 
sti sigur ca nici cea de a doua nu se va face. Daca însa prima ramificatie se va face 
atunci cea de a doua va depinde exclusiv de valoarea logica a conditiei "cond2". 
Asadar în mod cert aceste doua ramificatii sunt corelate, chiar daca comportarea 
celui de al doilea salt nu depinde exclusiv de comportarea primului. Sa consideram 
acum pentru analiza o secventa de program C simplificata împreuna cu secventa 
obtinuta în urma compilarii (s-a presupus ca variabila x este asignata registrului 
RI). 

if (x ==0) bl) BNEZ RI,LI 


X= ADD RI, RO, #1 


if (x == 1) LI: SUB R3,RI1, #1 
(b2)  BNEZ R3,12 
Se poate observa ca daca saltul conditionat b1 nu se va face, atunci nici b2 nu 
se va face, cele 2 salturi fiind deci corelate. Vom particulariza secventa anterioara, 
considerând iteratii succesive ale acesteia pe parcursul carora x variaza de exemplu 
între 0 si 5. Un BPB clasic, initializat pe predictie NU, având un singur bit de 
predictie, s-ar comporta ca în tabelul 2.3. Asadar o astfel de schema ar predictiona 


în acest caz, întotdeauna gresit! 


Tabelul 2.3. Modul de predictionare al unui BPB clasic 
Predictie | Actiune | Predictie | Predictie | Actiune | Predictie 
b1 b1 noua bi b2 b2 noua b2 


Sa analizam acum comportarea unui predictor corelat având un singur bit de 
corelatie (se coreleaza deci doar cu instructiunea de salt anterior executata) si un 
singur bit de predictie. Acesta se mai numeste si predictor corelat de tip (1, 1). 
Acest predictor va avea 2 biti de predictie pentru fiecare instructiune de salt: primul 
bit predictioneaza daca instructiunea de salt actuala se va face sau nu, în cazul în 


care instructiunea anterior executata nu s-a facut iar al doilea analog, în cazul în 


care instructiunea de salt anterior executata s-a facut. Exista deci urmatoarele 4 


posibilitati (tabelul 2.4). 


Tabelul 2.4. Semnificatia bitilor de predictie pentru o schema corelata 


Biti predictie Predictie daca precedentul salt nu Predictie daca 


s-a facut precedentul salt s-a 


facut 


Ca si în cazul BPB-ului clasic cu un bit, în cazul unei predictii care se 


dovedeste a fi eronata bitul de predictie indicat se va complementa. Comportarea 
predictorului (1,1) pe secventa anterioara de program este prezentata în continuare 
(s-a considerat ca bitii de predictie asociati salturilor bl si b2 sunt initializati pe NU 


I NU). 


Tabelul 2.5. Modul de predictionare al unei scheme corelate 


Predictie | Actiune | Predictie | Predictie | Actiune | Predictie 
bi bi noua b1 b2 b2 noua b2 


Fs | oa [oanu [emo | oa nana 


o | pamu | mu [pamo [uree | mu [oma 
o | oam | oa | pamu [numa | va [ooma 
o | pane m [pan [numa nu [aa 


Dupa cum se observa in tabelul 2.5, singurele doua predictii incorecte sunt 
cand x = 5 in prima iteratie. În rest, predictiile vor fi întotdeauna corecte, schema 
comportându-se deci foarte bine spre deosebire de schema BPB clasica. În cazul 
general, un predictor corelat de tip (m,n) utilizeaza comportarea precedentelor m 


instructiuni de salt executate, alegând deci o anumita predictie de tip Da sau Nu din 


2M posibile iar n reprezinta numarul bitilor utilizati în predictia fiecarui salt. În 
cazul unei bucle, o înregistrare a istoriei saltului sub forma 011111111 (m=9) 
conduce în mod cert la o predictie corecta a saltului ('0', adica nu se va face pentru 
ca dupa 8 iteratii consecutive, în a noua iteratie se va iesi din bucla), ceea ce printr- 
un predictor clasic BTB e mai dificil de predictionat dupa cum deja am aratat; de 
asemenea o comportare alternativa a unui salt este simplu de predictionat printr-o 
schema corelata, în schimb printr-o schema clasica este foarte dificil. Asadar 
schemele corelate sunt eficiente atunci când predictia depinde si de un anumit 
pattern al istoriei saltului de predictionat, corelatia fiind în acest caz particular cu 
istoria pe m biti chiar a acelui salt si nu cu istoria anterioarelor m salturi. 

Un alt avantaj al acestor scheme este dat de simplitatea implementarii 
hardware, cu putin mai complexa decât cea a unui BPB clasic. Aceasta se bazeaza 
pe simpla observatie ca "istoria" celor mai recent executate m salturi din program, 
poate fi memorata într-un registru binar de deplasare pe m ranguri (registru de 
predictie). Asadar adresarea cuvântului de predictie format din n biti si situat într-o 


tabela de predictii, se poate face foarte simplu prin concatenarea c.m.p.s. biti ai PC- 


ului instructiunii de salt curente cu acest registru de deplasare in adresarea BPB- 
ului de predictie. Ca si in cazul BPB-ului clasic, un anumit cuvant de predictie 
poate corespunde la mai multe salturi. Exista in implementare 2 nivele deci: un 
registru de predictie al carui continut concatenat cu PC- ul c.m.p.s. al instructiunii 
de salt pointeaza la un cuvânt din tabela de predictii (aceasta contine bitii de 
predictie, adresa destinatie, etc.). În [Yeh92], nu se face concatenarea PC - registru 
de predictie si în consecinta se obtin rezultate nesatisfacatoare datorita 
interferentei diverselor salturi la aceeasi locatie din tabela de predictii, lucru 
constatat si eliminat de noi prin simulari proprii dupa cum se va arata într-un viitor 
capitol al acestei lucrari. 

În [Pan92], o lucrare de referinta în acest plan, se analizeaza calitativ si 
cantitativ într-un mod foarte atent, rolul informatiei de corelatie, pe exemple 
concrete extrase din benchmark-urile SPECint '92. Se arata ca bazat pe predictoare 
de tip numaratoare saturate pe 2 biti, schemele corelate (5-8 biti de corelatie 
utilizati) ating acurateti ale predictiilor de pâna la 11% în plus fata de cele clasice. 

De remarcat ca un BPB clasic reprezinta un predictor de tip (0,n), unde n este 
numarul bitilor de predictie utilizati. Numarul total de biti utilizati în 
implementarea unui predictor corelat de tip (m,n) este: 

N = 2 * n * NI, (2.10) 


unde NI reprezinta numarul de intrari al BPB-ului utilizat. 


Exista citate in literatura mai multe implementari Œ scheme de predictie a 
ramificatiilor, prima implementare comerciala a unei astfel de scheme facându-se 
în microprocesorul Intel Pentium Pro. Astfel de exemplu, implementarea tipica a 
unui predictor corelat de tip GAg (Global History Register, Global Prediction 
History Table) este prezentata în figura 2.28. Tabela de predictii PHT (Prediction 
History Table) este adresata cu un index rezultat din concatenarea a doua 
informatii ortogonale: PClow (i biti), semnificând gradul de localizare al saltului, 
respectiv registrul de predictie (HR- History Register pe k biti), semnificând 
"contextul" în care se situeaza saltul în program. De fapt, introducerea PClow în 
adresarea tabelei precum si introducerea tag-urilor în PHT, apartin autorului acestei 
lucrari. Ambele contributii s-au facut cu scopul eliminarii interferentelor branch- 
urilor în tabela de predictie. Adresarea PHT exclusiv cu HR ca în articolul 
[Yeh92], ducea la serioase interferente (mai multe salturi puteau accesa aceelasi 
automat de predictie din PHT), cu influente evident defavorabile asupra 
performantelor. Desigur, PHT poate avea diferite grade de asociativitate. Un 
cuvânt din aceasta tabela are un format similar cu cel al cuvântului dintr-un BTB. 
Se pare ca se poate evita concatenarea HR si PClow în adresarea PHT, cu rezultate 
foarte bune, printr-o functie de dispersie tip SAU EXCLUSIV între acestea, care sa 
adreseze tabela PHT. Aceasta are o influenta benefica asupra capacitatii tabelei 


PHT. 


În scopul reducerii interferentelor diverselor salturi în tabela de predictii, in 
[Yeh92] se prezinta o schema numita PAg- Per Address History Table, Global 


PHT, a carei structura este oarecum asemanatoare cu cea a schemei GAg. 


Componenta HR*(k) a introdus-o autorul acestei lucrari, având semnificatia 
componentei HR de la varianta GAg, adica un registru global care memoreaza 
comportarea ultimelor k salturi. Fara aceasta componenta, cred ca schema PAg si- 
ar pierde din capacitatea de adaptare la contextul programului în sensul în care 
schema GAg o face. În opinia mea, Yeh si Patt renunta într-un mod curios si gresit 
la informatia de corelatie globala (HRg) în trecerea de la schemele de tip GAg la 
cele de tip PAg, în favoarea exclusiva a informatiei de corelatie locala (HRI). În 
schimb, componenta HR din structura History Table, contine "istoria locala” 
(taken/ not taken) a saltului curent, ce trebuie predictionat. Dupa cum se va arata 
mai departe, performanta schemei PAg este superioara celei obtinute printr-o 


schema de tip GAg, cu tributul de rigoare platit complexitatii hardware. 


Piw ti ee 


zi 


intrari asociative 


i+k 


Figura 2.28. Structura de predictie de tip GAg 


Pei ti [stu 


History Table 


zi 


intrari asociative 


Figura 2.29. Structura de predictie de tip PAg 


Asadar aceasta schema de tip PAg predictioneaza pe baza a 3 informatii 
ortogonale, toate disponibile pe chiar timpul fazei IF: istoria HRg a anterioarelor 
salturi corelate (taken / not taken), istoria saltului curent HRI si PC-ul acestui salt. 
Daca adresarea tabelei PHT s-ar face in schema PAg cu HR concatenat cu 
PClow(1), atunci practic fiecare branch ar avea propria sa tabela PHT, rezultând 
deci o schema si mai complexa numita PAp (Per Address History Table, Per 
Address PHT) [Yeh92], a carei schema de principiu este prezentata mai jos (figura 
2.30). Complexitatea acestei scheme o face practic neimplementabila în siliciu la 


ora actuala, fiind doar un model utilizat în cercetare. 


PBHT 


PCh | PC) ti) |HRglk]| 


{i+k) bits 


2] associative entries 


HIT 


Figura 2.30. Structura de predictie de tip PAp 

Desigur, este posibil ca o parte dintre branch-urile memorate în registrul HR, 
sa nu se afle în corelatie cu branch-ul curent, ceea ce implica o serie de 
dezavantaje. În astfel de cazuri pattern-urile din HR pot pointa în mod inutil la 
intrari diferite în tabela de predictii, fara beneficii asupra performantei predictiei, 
separându-se astfel situatii care nu trebuiesc separate. Mai mult, aceste situatii pot 
conduce la un timp de "umplere" a structurilor de predictie mai îndelungat, cu 
implicatii defavorabile asupra performantei [Eve98]. 

În opinia autorului acestei monografii, o critica valabila pentru toate 
schemele corelate consta în faptul ca informatia de corelatie globala (HRg) este 
insuficienta în predictie. Mai precis, de exemplu în predictia saltului curent notat 
b4, sa consideram ca se dispune de continutul lui HRg = 101 si respectiv HRI = 01. 
De asemenea sa consideram ca cele 3 salturi anterioare celui curent si a caror 
comportare (taken / not taken) este data de continutul HRg (101 aici), au fost bl, 
b2 si b3. Într-o urmatoare instanta a aparitiei saltului b4 în exact acelasi context al 
continuturilor HRg si HRI ca cel precedent, se va apela acelasi automat de predictie 
accesat de anterioara aparitie a lui b4. Acest fapt poate fi total ineficient având în 
vedere ca nu exista nici o garantie a faptului ca si de aceasta data, cele 3 salturi 
anterioare lui b4 au fost b1, b2 si b3, exact ca în cazul precedent. Prin urmare HRg 
nu poate "prinde" întreg contextul de aparitie al unui anumit salt (b4 aici). Acest 


lucru kam demonstrat pe baza de statistici în trace-urile benchmark-urilor Stanford, 


aratând ca exista salturi care in acelasi context (HRg, HRI) au comportari 
aberante, adica de ex. în 56% din cazuri s-au facut iar în 44% din cazuri, nu s-au 
facut. Prin urmare aceste salturi sunt practic inpredictibile, din motivul ca "acelasi 
context" nu este în realitate acelasi ! Solutia, în opinia mea, demonstrata de altfel la 
nivel de simulare software prin cercetari ale autorului si colaboratorilor sai aflate în 
curs, ar consta în asocierea fiecarui bit din HRg cu PC-ul aferent saltului respectiv 
Si accesarea predictiei pe baza acestei informatii mai complexe. Astfel, am putea 
avea siguranta ca la contexte diferite de aparitie a unui anumit salt, se vor apela 
automate diferite de predictie, asociate corect contextelor. Astfel s-ar reduce din 
efectele unui fenomen de interferenta a predictiilor înca nesesizat pâna acum. 
Compararea acestor noi scheme de predictie trebuie facuta cu scheme clasice având 
aceeasi complexitate structurala. Desigur, comprimarea acestui complex de 
informatie (HRg cu PC-urile aferente) este posibila si poate chiar necesara, având 
în vedere necesitatea unor costuri rezonabile ale acestor scheme. Ea se poate 
realiza prin utilizarea unor functii de dispersie simple (de ex. tip SAU- 
EXCLUSIV). Oricum, aceasta observatie simpla poate conduce la îmbunatatiri 
substantiale ale acuratetii de predictie, comparativ cu oricare dintre schemele 
actuale. Beneficiile unei asemenea idei novatoare pot fi preliminate cantitativ prin 
determinarea în cadrul unui anumit trace a directiei (taken / not taken), pentru 


fiecare instanta a unui anumit salt, aparut "în aceleasi context" dat HRg, HRI. 


Procentaje (mult) diferite 100% pentru directia predilecta a saltului, nu vor arata 
decat necesitatea implementarii acestei idei, dupa cum am mai aratat. 

O alta cauza a unor comportamente "aberante" ale ramificatiilor 
(comportamente diferite în contexte identice) poate fi cauzata de anumite pattern- 
uri mai "defavorabile" ale comportarii respectivului salt. Astfel de ex., un "loop" 
care se face de 99 de ori si o data nu se face, este practic imposibil de a fi 
predictionat corect 100% pe un context, normal, de genul HRg =111 respectiv 
HRI=11. De ce ? Pur si simplu pentru ca nu se stie daca acel 111 continut în HRg 
este sau nu este cel de dinaintea "catastrofei" (a momentului în care se iese din 
bucla). Ce informatii ar mai fi necesare atunci "prinderii" unor astfel de comportari 
imprevizibile. Fara îndoiala acele PC-uri asociate fiecarui bit din HRg vor fi inutile 
în acest caz, în schimb ar putea fi utila aici memorarea contorului de iteratii undeva 
în tabelele de predictie. Aceasta ipoteza ar putea fi confirmata prin simulari 
specifice. 

O comparare echitabila între schemele de predictie clasice si cele corelate 
trebuie sa impuna acelasi numar de biti utilizati în implementarea celor 2 scheme 
de comparat. Asa de exemplu în [Hen96] se compara un predictor (0,2) de 
capacitate 4k cu predictor (2,2) de capacitate 1k. Acuratetea predictiilor schemei 
corelate este clar mai buna. Simularile s-au facut pe procesorul DLX bazat pe 10 


benchmark-uri SPECint 92. Schema corelata a obtinut predictii corecte in 82%- 


100% din cazuri. Mai mult, predictorul (2,2) obtine rezultate superioare in 
comparatie cu un BPB avand un numar infinit de locatii. 

Mai nou, având in vedere complexitatea tot mai mare a acestor predictoare, 
cu implicatii defavorabile asupra timpului de cautare in structurile aferente, se 
vehiculeaza ideea unor predictoare hibride, constând în mai multe predictoare 
relativ simple asociate diferitelor tipuri de salturi în mod optimal. Aceste 
predictoare se activeaza în mod dinamic, functie de tipul saltului care este în curs 
de predictionat. Aceasta solutie pare a fi cea care ar putea depasi performanta 
complicatelor predictoare corelate pe 2 nivele. 

O problema dificila în predictia branch-urilor o constituie salturile codificate 
în moduri de adresare indirecte, a caror acuratete a predictiei este deosebit de 
scazuta prin schemele anterior prezentate (cca.50%). În [Cha97] se propune o 
structura de predictie numita "target cache” special dedicata salturilor indirecte. În 
acest caz predictia adresei de salt nu se mai face pe baza ultimei adrese tinta a 
saltului indirect ca în schemele de predictie clasice, ci pe baza alegerii uneia din 
ultimele adrese tinta ale respectivului salt, memorate în structura. Asadar, în acest 
caz structura de predictie, memoreaza pe parcursul executiei programului pentru 
fiecare salt indirect ultimele N adrese tinta. 

Predictia se va face deci în acest caz pe baza urmatoarelor informatii: PC-ul 


saltului, istoria acestuia, precum si ultimele N adrese tinta înregistrate. Structura de 


principiu a target cache-ului e prezentata in figura urmatoare, 2.31. O linie din 


acest cache contine ultimele N adrese tinta ale saltului impreuna cu tag-ul aferent. 


Target cache 


Adresa salt 


e 


info "istorie" Adresa tinta 


Figura 2.31. Predictia adresei în cazul salturilor indirecte 

Informatia "istorie" provine din doua surse: istoria saltului indirect sau a 
anterioarelor salturi si respectiv ultimele N adrese tinta, înscrise în linia 
corespunzatoare din cache. Aceste doua surse de informatie binara sunt prelucrate 
prin intermediul unei functii de dispersie (SAU EXCLUSIV), rezultând indexul de 
adresare in cache si tag-ul aferent. Dupa ce adresa tinta a saltului devine efectiv 
cunoscuta, se va introduce în linia corespunzatoare din cache. Schema actioneaza 
"în mod disperat", mizând pe faptul ca la acelasi context de aparitie a unui salt 
indirect se va asocia o aceeasi adresa tinta. Si în opinia mea, aceasta abordare 


principiala pare singura posibila în cazul acestor salturi greu predictibile. Prin astfel 


de scheme, masurat pe benchmark-urile SPECint '95 acuratetea predictiei salturilor 
indirecte creste si ca urmare, câstigul global asupra timpului de executie este de cca 
4.3% - 9% [Cha97]. 

O alta idee noua în predictia branch-urilor, din pacate putin mediatizata si 
întelesa în opinia mea, a fost lansata in 1996 [Mud96] si consta în predictia pe 
baza de lanturi Markov utilizând algoritmul PPM (Prediction by Partial 
Matching), utilizat de altfel si în procesarea (compresia) de imagini si 
recunoasterea vorbirii. Un predictor Markov de ordinul k predictioneaza bitul 
urmator pe baza celor k biti precedenti. În esenta pentru predictie, se cauta 
patternul memorat în registrul HRg pe k biti într-un sir binar mai lung al istoriei 
salturilor anterioare. Daca acest pattern este gasit în sirul respectiv cel putin o data, 
predictia se face corespunzator, pe baza unei statistici care determina de câte ori 
acest pattern a fost urmat în sir de 0 logic (non taken) si respectiv de câte ori a fost 
urmat de 1 logic (taken). Daca însa patternul din HRg nu a fost gasit în sirul de 
istorie, se construieste un nou pattern mai scurt prin eludarea ultimului bit din HRg 
si algoritmul se reia pe cautarea acestui nou pattern, s.a.m.d. pâna la gasirea unui 
anumit pattern în sir. Se arata ca desi complexitatea implementarii acestei noi 
scheme creste de cca. 2 ori fata de o schema corelata, eficienta sa - la acelasi buget 
al implementarii - este clar superioara. Nu sunt însa de acord cu autorii, care fara 
sa o demonstreze, sustin ca acest predictor reprezinta limita superioara a 


predictabilitatii ramificatiilor. 


În capitolul 5 al acestei lucrari se va prezenta un concept total nou în 
predictia ramificatiilor, introdus de catre autorul acestei lucrari, anume predictorul 
neuronal, bazat în cadrul procesului de predictie pe retele neuronale. 

În fine, o alta solutie mai agresiva decât cele precedente, consta în aducerea 
instructiunilor din cadrul ambelor ramuri ale branch-ului în structuri pipeline 
paralele (multiple instructions streams ). Când conditia de salt e determinata, una 
din ramuri se va abandona. Totusi, necesitatea predictiei apare si în acest caz 
datorita faptului ca în anumite cazuri (salturi indirecte, reveniri din subrutine) 
adresa de salt este necunoscuta la finele fazei IF si deci ar trebui predictionata în 
vederea procesarii eficiente. Apoi, chiar cunoscute ambele adrese, apare 
dificultatea adresarii memoriei si aducerii blocurilor de instructiuni de la aceste 2 
adrese distincte simultan din cache. Desigur ca în acest caz sunt necesare 
redundante ale resurselor hard (cache-uri, unitati de executie, busuri, logica de 
control, etc.) precum si complicatii în logica de control. Daca pe o ramura a 
programului exista de eemplu o instructiune de tip STORE, procesarea acestei 
ramuri trebuie oprita întrucât exista posibilitatea unei alterari ireparabile a unei 
locatii de memorie. Aceasta solutie implica cresteri serioase ale costurilor, dar se 
pare ca ar fi singura capabila sa se apropie oricât de mult fata de idealul predictiei 
absolut corecte. În cazul microprocesoarelor, aceste mecanisme de prefetch al 


ambelor ramuri, nu se aplica în prezent la microprocesoare, în principal datorita 


largimii de banda limitate între microprocesor si memorie. Tehnica s-a întâlnit in 
cazul supercomputerelor anilor '90 (ex. IBM-3033). 

Aceste tehnici de predictie hardware a branch-urilor, datorita complexitatii 
lor, nu sunt implementate în mod uzual în microprocesoarele RISC scalare, întrucât 
se prefera tehnicile software de "umplere" a BDS-ului (limitat în general la o 
instructiune) cu instructiuni utile, în general anterioare celei de salt, lucru posibil în 
cca. 70% -80% din cazuri. În schimb, predictia hardware este implementata în cazul 
unor procesoare superscalare, unde datorita BDS-ului de câteva instructiuni, 


umplerea lui cu instructiuni anterioare independente devine practic imposibila. 


2.4.5. PROBLEMA EXCEPTIILOR ÎN PROCESOARELE RISC 


La sesizarea unui eveniment de exceptie se vor inhiba bate procesele de 
scriere, atât pentru instructiunea care a provocat exceptia, cât si pentru urmatoarele 
aflate în banda. Aceasta previne orice modificare a contextului procesorului care ar 
putea fi cauzata de continuarea procesarii acestor instructiuni. În principiu, dupa 
terminarea instructiunii anterioare celei care a provocat exceptia, se intra in 
protocolul de tratare, în cadrul caruia se salveaza intern sau extern PC-ul 
instructiunii care a provocat exceptia, precum si contextul procesorului. În 
particular, în cazul în care instructiunea care a provocat exceptia se afla într-un 
BDS de ordinul n si saltul se face, atunci trebuie reluate cele n instructiuni BDS, 


precum si instructiunea la care se face saltul. În acest caz trebuie salvate (n + 1) 


PC-uri pentru ca in general adresele instructiunilor din BDS si respectiv adresa 
instructiunii la care se face saltul nu sunt contigue. 

Daca în cazul unei exceptii structura poate fi oprita astfel încât instructiunile 
anterioare celei care a provocat exceptia sa poata fi complet executate si respectiva 
instructiune împreuna cu cele ulterioare ei sa poata fi reluate în conditii 
deterministe, se zice ca avem o exceptie precisa. În caz contrar exceptia se zice 
imprecisa. Mai jos, se prezinta un exemplu de exceptie imprecisa : 

DIVF FO, F2, F4 
ADDF F6, F6, F8 
SUBF F10, F10, F14 

În acest caz instructiunile se vor termina Out of Order, adica ADDF si SUBF 
se vor termina înaintea instructiunii DIVF. Sa presupunem ca instructiunea DIVF a 
determinat o deruta aritmetica într-un moment în care ADDF si SUBF s-au 
încheiat. Aceasta situatie implica o exceptie imprecisa, întrucât reluarea 
instructiunii DIVF se va face cu continutul registrilor F6 si F10 alterat. Aceste 
situatii sunt evident nedorite, iar daca apar trebuie eliminate. Relativ la exceptiile 
imprecise, în literatura se precizeaza urmatoarele posibilitati de solutionare: 

a) Contextul CPU sa fie dublat printr-un asa-numit "history-file", care sa 
pastreze toate resursele modelului de programare. În acest "history-file" se înscriu 
noile rezultate la finele terminarii "normale" (pur secventiale) a instructiunilor. În 


cazul aparitiei unei exceptii imprecise contextul procesorului se va încarca din 


acest context de rezerva (ex. CYBER 180 / 990). Exista si alte variatiuni pe aceasta 
idee. 

b) Prin aceasta a 2-a solutie de principiu, nu se permite terminarea unei 
instructiuni in banda, pana cand toate instructiunile anterioare nu se vor fi terminat 
fara sa cauzeze o exceptie. Astfel se garanteaza ca daca a aparut o exceptie in 
cadrul unei instructiuni, nici o instructiune ulterioara acesteia nu sa încheiat si 
totodata instructiunile anterioare ei sau încheiat normal. Solutia implica întârzieri 
ale procesarii (ex. MIPS R 2000 / 3000). 

O alta problema o constituie exceptiile simultane. Daca luam în considerare 
o procesare pe 5 nivele, în cadrul fiecarui nivel pot apare urmatoarele exceptii : 

IF - deruta accesare pagina memorie, acces la un cuvânt nealiniat, etc. 

RD - cod ilegal de instructiune 

EX - diverse derute aritmetice (overflow) 

MEM - ca si la IF 

WB - acces la resurse privilegiate în modul de lucru user. 

Rezulta imediat posibilitatea aparitiei simultane a 2 sau mai multe 
evenimente de exceptie. Sa consideram spre exemplificare secventa de instructiuni 


din figura 2.32, în cadrul careia apar simultan doua exceptii: 


deruta accesare 


pagina memorie 
LOAD: IF RD EX/ MEM) WB 


ADD : IF RD\ EX MEM WB 
depasire aritmetica 


Figura 2.32. Exceptie simultana 


Solutia ar consta in tratarea prioritara a derutei instructiunii LOAD, dupa care 
se va relua aceasta instructiune. Apoi va apare deruta de depasire aferenta 
instructiunii ADD care va fi si ea tratata. 

Un caz mai dificil este acela in care exceptiile apar Out of Order ca in 


exemplul de mai jos: 


deruta accesare 
A pagina memorie 
i LOAD:IF RD EX WB date 
it] ADD : | IF RD EX MEM WB 
deruta accesare pagina 


memorie instructiuni 


Figura 2.33. Exceptii in ordine inversa 


În acest caz ar fi posibile 2 solutii de principiu : 
1) Sa existe un flag de stare exceptie aferent fiecarei instructiuni si care sa fie 
testat la intrarea în nivelul WB. Daca exista setata vreo exceptie, se va trece în 


protocolul de tratare. Astfel se garanteaza ca toate exceptiile din cadrul unei 


anumite instructiuni vor fi vazute înaintea exceptiilor aparute pe parcursul unei 
instructiuni urmatoare. 

2) Se bazeaza pe tratarea exceptiei de îndata ce aceasta a aparut 

La sesizarea derutei din cadrul instructiunii (i + 1) se vor inhiba instructiunile 
(i - 2), (G - 1), i, G + 1) si prin protocolul de tratare se va relua instructiunea (i - 2). 
Apoi se va sesiza deruta din cadrul instructiunii i urmând ca dupa tratarea ei 
instructiunea i sa se reia. Evident ca deruta aferenta nivelului IF din cadrul 
instructiunii (i + 1) a fost anterior eliminata si deci nu va mai apare. Mentionam ca 
majoritatea microprocesoarelor RISC detin suficiente resurse hardware interne care 
sa le permita în cazul aparitiei unei exceptii salvarea interna a contextului CPU. 
Evident ca limitarea resurselor interne nu implica limitarea posibilitatii de 
imbricare a exceptiilor. Ca si procesoarele CISC, procesoarele RISC detin registri 
de stare exceptie, registri care contin descrierea evenimentului de exceptie curent, 


registri care memoreaza adresa virtuala care a cauzat o exceptie, etc. 


2.4.6. AMBIGUITATEA REFERINTELOR LA MEMORIE 


Dependentele cauzate de variabilele aflate în memorie reprezinta o alta frâna 
în calea obtinerii performantei. Pentru exemplificare sa consideram secventa de 
program: 

ST 4(RI),RI 


LD R2, 8 ( Rj) 


Dupa cum deja am aratat, exista motive ca instructiunea LD sa se execute 
înaintea instructiunii ST din motive de eficienta a executiei (mascare latenta, 
beneficii legate de procesarea Out of order, etc.). Acest lucru este posibil numai 
daca cele 2 adrese de memorie sunt intotdeauna diferite. Este evident ca daca la un 
anumit moment ele sunt identice, semantica secventei se modifica inacceptabil. În 
general aceasta problema se rezolva static, de catre compilator, atunci când acest 
lucru e posibil. O componenta a acestuia ("disambiguating routine") compara cele 
2 adrese de memorie si returneaza una dintre urmatoarele 3 posibilitati: 

a) adrese întotdeauna distincte; 

b) adrese întotdeauna identice; 

c) cel putin 2 adrese identice sau nu se poate determina. 

Asadar, doar în primul caz putem fi siguri ca executia anterioara a 
instructiunii LD fata de instructiunea ST (sau simultana în cazul unui procesor 
MEM - Masina cu Executie Multipla, vezi capitolul 3) îmbunatateste performanta 
fara a cauza alterarea semantica a programului. Din pacate, nu se poate decide 
întotdeauna acest lucru în momentul compilarii. 

Dezambiguizarea statica da rezultate bune în cazul unor adresari liniare si 
predictibile ale memoriei (de ex. accesari de tablouri, matrici, etc.). Ea presupune 
rezolvarea unor ecuatii diofantice mai mult sau mai putin complexe, similare cu 
cele necesare vectorizarii buclelor de program [Sto93, Vin96]. Prin urmare un 


reorganizator de program bazat pe dezambiguizarea statica va fi deosebit de 


conservativ in actiunile sale. Daca aceasta comparare a adreselor de memorie se 
face pe parcursul procesarii programului prin hardware, se zice ca avem o 
dezambiguizare dinamica. Aceasta este mai performanta decât cea statica dar 
necesita resurse hardware suplimentare si deci costuri sporite [Ste96, Nic89, 
Hua94]. 

Pentru a pune în evidenta performanta superioara a variantei dinamice, sa 
consideram secventa: 

for i = 1 to 100 do 
al 2i ]=.... 
y= f(..., a[i+4],...) 
end 

Într-un singur caz din cele 100 posibile (i = 4), cele 2 referinte la memorie 
a[2i] respectiv ali + 4] sunt identice. Asadar, o dezambiguizare statica va fi 
conservativa, nepermitând optimizarea buclei desi doar in 99% din cazuri acest 
lucru este posibil. Pentru rezolvarea situatiei pe aceasta cale este necesara scoaterea 
din bucla a dependentelor de alias. O varianta dinamica însa, va putea exploata mai 
eficient acest fapt. Pe un procesor superscalar sau VLIW acest lucru este si mai 
avantajos întrucât cele 2 operatii din bucla se vor putea realiza simultan. Se 
considera ca progresele în aceasta problema pot duce la cresteri semnificative de 
performanta în domeniul paralelismului la nivelul instructiunilor, dupa cum vom 


demonstra si noi într-o contributie ulterioara. 


2.4.7. EXECUTIA CONDITIONATA SI SPECULATIVA 


Executia conditionata (predicativa) se refera la implementarea unor asa 
numite instructiuni conditionate. O instructiune conditionta se va executa daca o 
variabila de conditie inclusa in corpul instructiunii indeplineste conditia dorita. In 
caz contrar, instructiunea respectiva nu va avea nici un efect (NOP). Variabila de 
conditie poate fi memorata într-un registru general al procesorului sau în registri 
special dedicati acestui scop numiti registri booleeni. Astfel de exemplu, 
instructiunea CMOVZ RI, R2, R3 muta (R2) în RI daca (R3) = 0. Instructiunea 
TB5 FB3 ADD RI, R2, R3 executa adunarea numai daca variabilele booleene B5 
si B3 sunt '1' respectiv '0'. În caz contrar, instructiunea este inefectiva. Desigur ca 
variabilele booleene necesita biti suplimentari în corpul instructiunii. 

Executia conditionata a instructiunilor este deosebit de utila în eliminarea 
salturilor conditionate dintr-un program, simplificând programul si transformând 
deci hazardurile de ramificatie in hazarduri de date. Sa consideram spre 


exemplificare o constructie if-then-else ca mai jos: 


if (R8<1) LT B6, R8, #1; if R8<1, B6<---1 

R1 = R2 + R3, BF B6, Adrl; Daca B6=0 salt la Adr1 
else ADD RI, R2, R3 

RI = R5 - R7; BRA Adr? ,; salt la Adr2 


RIO=RI+RII; Adri: SUB R1, R5, R7 


Ad: ADD R10, R1, R11 


Prin rescrierea acestei secvente utilizând instructiuni conditionate se elimina 
cele 2 instructiuni de ramificatie obtinându-se urmatoarea secventa mai simpla si 
mai eficienta de program: 

LT B6, R8, #1 
TB6 ADD RI, R2,R3 
FB6 SUB RI,R5,R7 

ADD R10, R1, R11 

Este clar ca timpul de executie pentru aceasta secventa este mai mic decât cel 
aferent secventei anterioare. Se arata ca astfel de transformari reduc cu cca. 25- 
30% instructiunile de salt conditionat dintr-un program.[Col95, Ste96]. Aceasta 
executie conditionata a instructiunilor faciliteaza executia speculativa. Codul situat 
dupa un salt conditionat în program si executat înainte de stabilirea conditiei si 
adresei de salt cu ajutorul instructiunilor conditionate, se numeste cod cu executie 
speculativa, operatia respectiva asupra codului numindu-se predicare. Predicarea 
reprezinta o tehnica de procesare care - utilizând instructiuni cu executie 
conditionata - urmareste executia paralela prin speculatie a unor instructiuni si 
reducerea numarului de ramificatii din program, ambele benefice pt. minimizarea 
timpului de executie al programului. Acest mod de executie a instructiunilor poate 
fi deosebit de util în optimizarea executiei unui program. 

Prezentam în continuare o secventa de cod initiala si care apoi e transformata 


de catre scheduler în vederea optimizarii executiei prin speculatia unei instructiuni. 


SUB RI, R2, R3 SUB RI, R2, R3 


LT B8, R1, #10 LT B8, R1, #10 

BT B8, Adr FB8 ADD R7,R8, R1; speculativa 
ADD R7,R8,RI1 BT B8, Adr 

SUB R10, R7, R4 SUB R10, R7, R4 


Executia speculativa a instructiunii ADD putea fi realizata si în lipsa 
variabilelor de garda booleene dar atunci putea fi necesara redenumirea registrului 
R7 (daca acesta ar fi în viata pe ramura pe care saltul se face). Orice instructiune - 
cu exceptia celor de tip STORE - poate fi executata speculativ. O posibila strategie 
de a permite instructiuni STORE speculative consta în introducerea unui Data 
Write Buffer (DWB). Memorarea se va face întâi aici si abia când conditia de salt 
este cunoscuta se va înscrie în memorie [Col95]. Pe lânga avantajele legate de 
eliminarea salturilor, facilizarea executiei speculative, predicarii, etc., executia 
conditionata are si câteva dezavantaje dintre care amintim: 

- instructiunile conditionate anulate (NOP) necesita totusi un timp de 
executie. În cazul speculatiei, în aceste conditii performanta în executie scade. 

- daca variabila de conditie e evaluata târziu, utilitatea instructiunii 
conditionate va fi micsorata. 

- promovarea unei instructiuni peste mai multe ramificatii conditionate în 


vederea executiei speculative necesita gardari multiple. 


- instructiunile conditionate pot determina scaderea frecventei de tact a 
microprocesorului. 

Având în vedere cele de mai sus, utilitatea executiei conditionate este inca 
discutata. MIPS, POWER-PC, SUN-SPARC, DEC ALPHA detin doar o 
instructiune de tip MOVE conditionata, în timp ce alte microarhitecturi precum 
HEWLET PACKARD PA, HARP, HSA, etc., permit executia conditionata a 
majoritatii instructiunilor masina. La ora actuala exista înca putine evaluari 


cantitative care sa stabileasca avantajele/dezavantajele acestei idei într-un mod clar. 


3. PROCESOARE CU EXECUTII MULTIPLE ALE INSTRUCTIUNILOR 


3.1. CONSIDERATII GENERALE. PROCESOARE SUPERSCALARE SI 
VLIW 


Un deziderat ambitios este acela de se atinge rate medii de procesare de mai 
multe instructiuni per tact. Procesoarele care initiaza executia mai multor operatii 
simultan intr-un ciclu (sau tact) se numesc procesoare cu executii multiple ale 
instructiunilor. Un astfel de procesor aduce din cache-ul de instructiuni una sau mai 
multe instructiuni simultan si le distribuie spre executie în mod dinamic sau static 
(prin reorganizatorul de program), multiplelor unitati de executie. 

Principiul acestor procesoare paralele numite si "masini cu executie multipla" 


(MEM) consta în existenta mai multor unitati de executie paralele, care pot avea 


latente diferite. Pentru a facilita procesarea acestor instructiuni, acestea sunt 
codificate pe un singur cuvant de 32 sau 64 de biti uzual, pe modelul RISC anterior 
prezentat. Daca decodificarea instructiunilor, detectia dependentelor de date dintre 
ele, rutarea si lansarea lor in executie din bufferul de prefetch inspre unitatile 
functionale se fac prin hardware, aceste procesoare MEM se mai numesc si 


superscalare. 


Pot exista mai multe unitati functionale distincte, dedicate de exemplu 
diverselor tipuri de instructiuni tip întreg sau flotant. Asadar executiile 
instructiunilor întregi, se suprapun cu executiile instructiunilor flotante (FP-Flotant 
Point). În cazul procesoarelor MEM, paralelismul temporal determinat de 
procesarea pipeline se suprapune cu un paralelism spatial determinat de existenta 
mai multor unitati de executie. În general structura pipeline a coprocesorului are 
mai multe nivele decât structura pipeline a procesorului ceea ce implica probleme 
de sincronizare mai dificile decât în cazul procesoarelor pipeline scalare. Acelasi 
lucru este valabil si între diferite alte tipuri de instructiuni având latente de executie 
diferite. Caracteristic deci procesoarelor superscalare este faptul ca dependentele de 
date între instructiuni se rezolva prin hardware, în momentul decodificarii 
instructiunilor. Modelul ideal de procesare superscalara, în cazul unui procesor care 
poate aduce si decodifica 2 instructiuni simultan este prezentat în figura 3.1. 

Este evident ca în cazul superscalar complexitatea logicii de control este mult 
mai ridicata decât în cazul pipeline scalar, întrucât detectia si sincronizarile între 
structurile pipeline de executie cu latente diferite si care lucreaza în paralel devin 
mult mai dificile. De exemplu un procesor superscalar având posibilitatea aducerii 
Si executiei a "n" instructiuni masina simultan, necesita n(n-1)/2 unitati de detectie 
a hazardurilor de date între aceste instructiuni (comparatoare digitale), ceea ce 


conduce la o complexitate ridicata a logicii de control. 


Figura 3.1. Modelul executiei superscalare 


S-ar putea deci considera aceste procesoare MEM ca fiind arhitecturi de tip 
MIMD (Multiple Instructions Multiple Data) in taxonomia lui Michael Flynn. De 
remarcat totusi ca in aceasta categorie sunt introduse cu precadere sistemele 
multiprocesor care exploateaza paralelismul la nivelul mai multor aplicatii (coarse 
grain parallelism), arhitecturile RISC ca si cele de tip MEM exploatând 
paralelismul instructiunilor la nivelul aceleiasi aplicatii (fine grain parallelism). 
Desigur ca - din punctul de vedere al acestei taxonomii - arhitecturile pipeline 
scalare (RISC), ar fi incadrabile in clasa SISD (Single Instruction Single Data), 
fiind deci incluse in aceeasi categorie cu procesoarele cele mai conventionale 
(secventiale), ceea ce implica o slabiciune a acestei sumare taxonomii. 

În figura 3.2 se prezinta o structura tipica de procesor superscalar care detine 
practic 2 module ce lucreaza în paralel: un procesor universal si un procesor 
destinat operatiilor în virgula mobila. Ambele module detin unitati de executie 
proprii având latente diferite. La anumite microprocesoare superscalare registrii 


CPU sunt diferiti de registrii FP, pentru a se reduce hazardurile structurale (în 


schimb cresteri serioase ale costurilor si dificultati tehnologice) iar la altele (de ex. 
Motorola 88100), registrii CPU sunt identici cu cei ai coprocesorului [Mot91, 
Mic90]. De exemplu, pentru eliminarea hazardurilor structurale, multe dintre aceste 
microprocesoare nu detin "clasicul" registru d indicatorilor de conditie. Salturile 
conditionate se realizeaza prin compararea pe o anumita conditie, a 2 dintre 
registrele codificate in instructiune. Hazardurile structurale la resursele hardware 


interne se elimina prin multiplicarea acestora si sincronizarea adecvata a 
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Figura 3.2. Structura de procesor superscalar pipeline 


De remarcat ca procesoarele superscalare, determina apropierea ratei de 
executie la una sau, în cazul în care se pot aduce mai multe instructiuni simultan, la 
mai multe instructiuni per ciclu. Dificultatile de sincronizare sporite, se rezolva 


prin utilizarea unor tehnici hardware bazate pe "scoreboarding" deosebit de 


sofisticate. Majoritatea microprocesoarelor RISC actuale sunt de tip superscalar 
(contin cel putin un coprocesor integrat in chip). Un procesor superscalar care 
aduce din cache-ul de instructiuni mai multe instructiuni primitive simultan, poate 
mari rata de procesare la 1.2-2.3 instr./ciclu masurat pe o mare diversitate de 
benchmark-uri, la nivelul realizarilor practice între anii 1995-1998. Exemple 
remarcabile de microprocesoare superscalare comerciale de tip RISC, sunt: INTEL 
960 CA, SUN SuperSPARC, MPC 601, 603, 620 (POWER PC), etc. 
Microprocesoarele Intel Pentium, AMD K6, etc., sunt practic procesoare având 
model de programare CISC dar executie hardware superscalara. 

Procesoarele VLIW (Very Long Instruction Word) reprezinta procesoare care 
se bazeaza pe aducerea in cadrul unei instructiuni multiple a mai multor 
instructiuni RISC independente pe care le distribuie spre procesare unitatilor de 
executie. Asadar, rata de executie ideala la acest model, este de n instructiuni/ciclu. 
Pentru a face acest model viabil, sunt necesare instrumente soft de exploatare a 
paralelismului programului, bazate pe gruparea instructiunilor simple independente 
si deci executabile în paralel, în instructiuni multiple. Arhitecturile VLIW sunt tot 


de tip MEM. Principiul VLIW este sugerat în fig. 3.3: 


BLOC DECODIFICARE & ALOCARE 


INSTRUCTIUNE MULTIPLA [4 INSTR.) 


Figura 3.3. Decodificarea si alocarea instructiunilor int-un procesor VLIW 


În cadrul acestui model, se încearca prin transformari ale programului, ca 
instructiunile RISC primitive din cadrul unei instructiuni multiple sa fie 
independente si deci sa se evite hazardurile de date între ele, a caror gestionare ar fi 
deosebit de dificila în acest caz. Performanta procesoarelor VLIW este esential 
determinata de programele de compilare si reorganizare care trebuie sa fie deosebit 
de "inteligente". De aceea acest model de arhitectura se mai numeste uneori si 
EPIC (Explicitly Parallel Instruction Computing). 

Prin urmare, în cazul modelului de procesor VLIW, compilatorul trebuie sa 
înglobeze mai multe instructiuni RISC primitive independente în cadrul unei 
instructiuni multiple, în timp ce în cazul modelului superscalar, rezolvarea 
dependentelor între instructiuni se face prin hardware, începând cu momentul 
decodificarii acestor instructiuni. De asemenea, pozitia instructiunilor primitive 
într-o instructiune multipla determina alocarea acestor instructiuni primitive la 
unitatile de executie, spre deosebire de modelul superscalar unde alocarea se face 


dinamic prin control hardware. Acest model de procesor nu mai necesita 


sincronizari si comunicatii de date suplimentare intre instructiunile primitive dupa 
momentul decodificarii lor, fiind astfel mai simplu din punct de vedere hardware 
decât modelul superscalar. Un model sugestiv al principiului de procesare VLIW 


este prezentat în figura3.4. 


Figura 3.4. Principiul de procesare VLIW 


Pentru exemplificarea principiului de procesare MEM, sa consideram 


secventa de program de mai jos : 


LOOP: LD FOORI) 
ADD F4,F0,F2 
SD O(R1),F4 


SUB R1,R1,#8 
BNEZ R1, LOOP 
Se va analiza in continuare cum ar trebui reorganizata si procesata secventa 
de program anterioara pentru a fi executata pe un procesor VLIW care poate aduce 
maxim 5 instructiuni primitive simultan si detine 5 unitati de executie distincte si 
anume: 2 unitati LOAD / STORE (MEMI, MEM2), 2 unitati de coprocesor flotant 


(FPP1, FPP2) si o unitate de procesare a instructiunilor întregi si respectiv a 


branch-urilor. 


Tabelul 3.1. Executia instructiunilor pe un procesor MEM cu 5 unitati de executie specializate 


O MEMI | MEM 2 FPP FPP 2____ CPU / BRANCH 
Loop: LD FO, 0(R1) | LD F6, BIRT || 
LD F10, -16(R1) LD FIA, ARI) | 
A 
ADD F12, F10, F2 [ADD F16,F14, 


ADD F20, F18, F2 [ADD F24,F22, 
D OfR1), FA SD -8(R1), F8 ADD F28, F26, F2 
D -16[R1), F12 SD -24(R1), F16 
D 


| 

SD -32[R1], F20 SD -40[R1}, F24| | SUB RI, Ri, #48 
Me | 
| 


SD O(R1). F28 BNEZ RI, Loop 
Doo LNOP | 


De remarcat în acest caz o rata medie de procesare de 2.4 instructiuni / ciclu. 
Altfel spus, bucla de program anterioara se executa în doar 1.42 cicli (10 cicli / 7 
bucle). De remarcat printre altele, o redenumire a registrilor absolut necesara 
acestei procesari agresive. Posibilitatile hard / soft aferente unei asemenea 
procesari vor fi prezentate succint în continuare. Este clar ca performanta 
procesoarelor MEM este esential determinata de programele de compilare si 
reorganizare care trebuie sa fie deosebit de "inteligente". Cercetari realizate in 
comun la Universitatea Stanford, USA si firma DEC (Digital Equipment 
Corporation) pe procesoare VLIW cu 4 instructiuni simultane, au aratat ca în 
aplicatii reale se ajunge la executia a max 2 - 3 instructiuni / ciclu, prin 
compilatoare optimizate. Desi rare, exista realizari comerciale de computere VLIW 
cu software de optimizare de oarecare succes pe piata : IBM RS / 6000 ( 4 


instructiuni / ciclu , teoretic), INTEL 80 (maxim 2 instructiuni / ciclu), APOLLO 


DN 10000, etc. Aceste realizari sunt disponibile comercial începând cu anul 1991, 
desi cercetarile au fost initiate începând din 1983. Firma Intel a anuntat ca noul sau 
model de procesor având numele de cod Merced (IA-64), ce va fi lansat în anii 
1999 - 2000, va fi realizat pe principii VLIW (EPIC). Având în vedere ca în cadrul 
acestor arhitecturi compilatorul este puternic senzitiv la orice modificare hardware, 
personal prevad o legatura hardware - software mai pronuntata decât cea actuala 
(1998), începând cu lansarea comerciala a acestei arhitecturi noi. Necesitatile de 
"upgrade" hardware - software, cred de asemenea vor fi mai imperioase prin 
aceasta filosofie EPIC, necesitând deci mai mult decât pâna acum din partea 
utilizatorilor, serioase si continue investitii financiare corespunzator noilor modele. 
IA-64 (Intel Architecture) va fi prima arhitectura Intel pe 64 de biti care va îngloba 
doua caracteristici esentiale descrise deja în capitolul 2: executia conditionata prin 
variabile de garda booleene a instructiunilor (“executie predicativa”) si respectiv 
executia speculativa a instructiunilor — cu beneficii asupra mascarii latentei unor 
instructiuni mari consumatoare de timp si deci asupra vitezei de procesare. 
Arhitectura se bazeaza pe explicitarea paralelismului instructiunilor la nivelul 
compilatorului într-un mod similar cu cel din arhitecturile VLIW. Intel sustine ca 
programele optimizate pe o anumita masina IA-64 vor functiona fara probleme pe 
oricare alta viitoare masina întrucât latentele unitatilor de executie ca si numarul 
acestora sunt invizibile pentru optimizatorul de cod. Aceasta se realizeaza însa prin 


interconectarea totala a unitatilor de executie care se sincronizeaza prin tehnici de 


tip “scoreboarding” [Dul98]. Rezulta deci ca un program obiect portat de la o 
versiune mai veche de procesor la alta mai noua, chiar daca va functiona totusi 
corect, se va procesa mai lent decat daca ar fi optimizat special pentru noua 
varianta de procesor. 

Dificultatile principale ale modelului VLIW sunt urmatoarele: 

- Paralelismul limitat al aplicatiei, ceea ce determina ca unitatile de executie 
sa nu fie ocupate permanent, fapt valabil de altfel si la modelul superscalar. 

- Incompatibilitate software cu modele succesive si compatibile de 
procesoare care nu pot avea in general un model VLIW identic datorita faptului ca 
paralelismul la nivelul instructiunilor depinde de latentele operatiilor procesorului 
scalar, de numarul unitatilor functionale si de alte caracteristici hardware ale 
acestuia. 

- Dificultati deosebite în reorganizarea aplicatiei (scheduling) în vederea 
determinarii unor instructiuni primitive independente sau cu un grad scazut de 
dependente. 

- Cresterea complexitatii hardware si a costurilor ca urmare a resurselor 
multiplicate, cailor de informatie "latite", etc. 

- Cresterea necesitatilor de memorare ale programelor datorita reorganizarilor 
soft si "impachetarii" instructiunilor primitive în cadrul unor instructiuni multiple 
care necesita introducerea unor instructiuni NOP (atunci când nu exista instructiuni 


de un anumit tip disponibile spre a fi asamblate într-o instructiune multipla). 


În esenta, prin aceste modele MEM se încearca exploatarea paralelismului 
din programe secvențiale prin excelenta, de unde si limitarea principala a acestui 
domeniu de "low level parallelism". 

Actualmente, datorita faptului ca aceste procesoare sunt mult mai ieftine 
decât procesoarele vectoriale (superprocesoare), si totodata foarte performante, se 
pune problema determinarii unor clase largi de aplicatii în care modele superscalar, 
superpipeline si VLIW sa se comporte mai bine sau comparabil cu modelul 
vectorial [Hen96, Sto93]. Se poate arata relativ simplu, ca din punct de vedere 
teoretic performanta unui procesor superscalar având N unitati functionale, fiecare 
cu o structura pipeline pe M nivele, este echivalenta cu cea a unui procesor scalar 
superpipeline cu o structura pipeline pe M*N nivele. Asocierea unei arhitecturi 
optimale unei clase de aplicatii data, este o problema dificila. Performanta 
procesoarelor scalare superpipeline, superscalare si VLIW este în strânsa legatura 
cu progresele compilatoarelor specifice acestor structuri, compilatoare care trebuie 
sa extraga cât mai mult din paralelismul existent la nivelul instructiunilor 
programului. 

De remarcat ca modelele superscalar si VLIW nu sunt exclusive, în 
implementarile reale se întâlnesc adesea procesoare hibride, în încercarea de a se 
optimiza raportul performanta pret. Dupa cum se va vedea, spre exemplu tehnicile 
soft de optimizare sunt comune ambelor variante de procesoare. Aceste modele 


arhitecturale de procesoare paralele sunt considerate a face parte din punct de 


vedere arhitectural, din generatia a III-a de microprocesoare, adica cea a anilor 


1990 - 2000. 


3.2. MODELE DE PROCESARE IN ARHITECTURILE SUPERSCALARE 


În cazul procesoarelor superscalare sunt citate în literatura de specialitate 3 
modalitati distincte de procesare si anume: In Order Issue In Order Completion (IN 
- IN), In Order Issue Out of Order Completion (IN - OUT) si respectiv Out of 
Order Issue Out of Order Completion (OUT -OUT). Pentru exemplificarea 
afirmatiei de mai sus, sa consideram o secventa de instructiuni Il - I6 cu 
urmatoarele particularitati: I1 necesita 2 cicli pentru executie, I3 si I4 sunt in 
conflict structural, între I4 si I5 exista dependenta RAW iar I5 si I6 sunt de 
asemenea in conflict structural. În aceste conditii si considerând un procesor 
superscalar care poate aduce si decodifica 2 instructiuni simultan si care detine 2 
unitati de executie, avem situatiile urmatoare pe cele trei modele: 

a) Modelul IN - IN 

Este caracterizat prin faptul ca procesorul nu decodifica urmatoarea pereche 
de instructiuni, decât în momentul în care perechea anterioara se executa. Asadar 
atât executia cât s înscrierea rezultatelor se face în ordinea din program ca în 


figura. 


Tabelul 3.2. Exemplu de procesare IN-IN 


DECODIFICARE EXECUŢIE WB 


O NN II hw N = 


b) Modelul IN - OUT 

Este caracterizat de faptul ca executia propriu-zisa se face în ordine, în 
schimb înscrierea rezultatelor se face de îndata ce o instructiune s-a terminat de 
executat. Modelul este mai eficient decât cel precedent însa poate crea probleme de 
genul întreruperilor imprecise care trebuiesc evitate prin tehnici deja amintite în 


capitolul 2. 


Tabelul 3.3. Exemplu de procesare IN-OUT 


DECODIFICARE EXECUȚIE WB 
UEI UE2 


c) Modelul OUT - OUT 

Este cel mai agresiv si performant model de procesare a instructiunilor într- 
un procesor superscalar. Instructiunile sunt aduse si decodificate sincron, 
presupunând deci existenta unui buffer între nivelul de decodificare si executie 
(instructions window). Astfel creste capacitatea de anticipare a instructiunilor 
independente dintr-un program. Modelul permite o exploatare mai buna a 
paralelismului instructiunilor la nivelul unui program dat, prin cresterea 


probabilitatii de determinare a unor instructiuni independente, stocate în buffer. 


Tabelul 3.4. Exemplu de procesare OUT-OUT 
DECODIFICARE EXECUŢIE WB 


Desigur ca executia Out of Order este posibila numai atunci cand 
dependentele de date între instructiuni o permit. Cade in sarcina hardului 
eliminarea dependentelor si alocarea instructiunilor din buffer la diversele unitati 


de executie (rutarea). 


3.3. ARHITECTURA LUI R. TOMASULO 


A fost proiectata si implementata pentru prima data in cadrul unitatii de 
calcul in virgula mobila din cadrul sistemului IBM - 360 / 91 si este atribuita lui 
Roberto Tomasulo [Tom67, Hen96, Vin96], considerat a fi fost pionierul procesarii 
superscalare si pe acest motiv, laureat al prestigiosului premiu Eckert Mauchly 
Award pe anul 1996, acordat celor mai performanti constructori si proiectanti de 
calculatoare. Arhitectura este una de tip superscalar avand deci mai multe unitati de 
executie, iar algoritmul de control al acestei structuri stabileste relativ la o 
instructiune adusa, momentul în care aceasta poate fi lansata in executie si 
respectiv unitatea de executie care va procesa instructiunea. Arhitectura permite 
executia multipla si Out of Order a instructiunilor si constituie modelul de referinta 
în reorganizarea dinamica a instructiunilor într-un procesor superscalar. De 
asemenea, algoritmul de gestiune aferent arhitecturii permite anularea hazardurilor 
WAR si WAW printr-un ingenios mecanism hardware de redenumire a registrilor, 
fiind deci posibila executia Out of Order a instructiunilor si în aceste cazuri. 
Asadar, singurele hazarduri care impun executia In Order sunt cele de tip RAW. 

În cadrul acestei arhitecturi, detectia hazardurilor si controlul executiei 
instructiunilor sunt distribuite iar rezultatele instructiunilor sunt "pasate anticipat" 
direct unitatilor de executie prin intermediul unei magistrale comune numita CDB 
(Common Data Bus). Arhitectura de principiu este prezentata în fig.3.5. Ea a fost 
implementata prima data în unitatea de virgula mobila FPP a calculatorului IBM 


360/91, pe baza careia se va prezenta în continuare. Statiile de rezervare (SR) 


memoreaza din SIF (Stiva Instructiuni Flotante - pe post de buffer de prefetch aici) 
instructiunea ce urmeaza a fi lansata spre executie. Executia unei instructiuni 
începe daca exista o unitate de executie neocupata momentan si daca operanzii 
aferenti sunt disponibili în SR aferenta. Fiecare unitate de executie (ADD, MUL) 
are asociata o SR proprie. Precizam ca unitatile ADD executa operatii de adunare / 
scadere iar unitatile MUL operatii de înmultire / împartire. Modulele LB si SB 
memoreaza datele încarcate din memoria de date respectiv datele care urmeaza a fi 
memorate. Toate rezultatele provenite de la unitatile de executie si de la bufferul 
LB sunt trimise pe magistrala CDB. Bufferele LB, SB precum si SR detin câmpuri 


de 'TAG necesare în controlul hazardurilor de date între instructiuni. 
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Figura 3.5. Arhitectura lui Tomasulo 


Exista in cadrul acestei unitati de calcul in virgula mobila si deci in cadrul 
mai general al procesarii superscalare, 3 stagii de procesare a instructiunilor si 
anume: 

1) Startare - aducerea unei instructiuni din SIF (bufferul de prefetch) într-o 
statie de rezervare. Aducerea se va face numai daca exista o SR disponibila. Daca 
operanzii aferenti se afla in FPR (setul de registri generali), vor fi adusi in SR 
aferenta. Daca instructiunea este de tip LOAD / STORE, va fi incarcata într-o SR 
numai daca exista un buffer (LB sau SB) disponibil. Daca nu exista disponibila o 
SR sau un buffer, rezulta ca avem un hazard structural si instructiunea va astepta 
pana cand aceste resurse se elibereaza. 

2) Executie - daca un operand nu este disponibil, prin monitorizarea 
magistralei CDB de catre SR ("snooping" - spionaj), se asteapta respectivul 
operand. În aceasta faza se testeaza existenta hazardurilor de tip RAW între 
instructiuni. Când ambii operanzi devin disponibili, se executa instructiunea în 
unitatea de executie corespunzatoare. 

3) Scriere rezultat (WB) - când rezultatul este disponibil se înscrie pe CDB si 
de aici in FPR sau într-o SR care asteapta acest rezultat ("forwarding"). 

De observat ca nu exista pe parcursul acestor faze testari pentru hazarduri de 
tip WAR sau WAW, acestea fiind eliminate prin însasi natura algoritmului de 
comanda dupa cum se va vedea imediat. De asemenea, operanzii sursa vor fi 


preluati de catre SR direct de pe CDB prin "forwarding" când acest lucru este 


posibil. Evident ca ei pot fi preluati si din FPR in cazurile in care nu vor fi produsi 
de instructiunile din statiile de rezervare sau din unitatile de executie. 

O SR detine 6 câmpuri cu urmatoarea semnificatie: 

OP - codul operatiei (opcode) instructiunii din SR. 

Qj, Qk - codifica pe un numar de biti unitatea de executie (ADD, MUL, etc.) 
sau numarul bufferului LB, care urmeaza sa genereze operandul sursa aferent 
instructiunii din SR. Daca acest câmp este zero, rezulta ca operandul sursa este deja 
disponibil într-un câmp Vi sau Vj al SR sau pur si simplu nu este necesar. 
Câmpurile Qj, Qk sunt pe post de TAG, adica atunci când o unitate de executie sau 
un buffer LB "paseaza" rezultatul pe CDB, acest rezultat se înscrie în câmpul Vi 
sau Vj al acelei SR al carei TAG coincide cu numarul sau numele unitatii de 
executie sau bufferului LB care a generat rezultatul. 

Vj, Vk - contin valorile operanzilor sursa aferenti instructiunii din SR. 
Remarcam ca doar unul dintre câmpurile Q respectiv V sunt valide pentru un 
anumit operand. 

BUSY - indica atunci când este setat ca SR si unitatea de executie aferenta 
sunt ocupate momentan. 

Registrii generali FPR si bufferele SB detin fiecare de asemenea câte un 
câmp Qi, care codifica numarul unitatii de executie care va genera data ce va fi 
încarcata în respectivul registru general respectiv care va fi stocata în memoria de 


date. De asemenea, detin câte un bit de BUSY. Bufferele SB detin în plus un câmp 


care contine adresa de acces precum si un câmp care contine data de înscris. 
Bufferele LB contin doar un bit BUSY si un câmp de adresa. 
Spre a exemplifica functionarea algoritmului sa consideram în continuare o 
secventa simpla de program masina: 
Start Executie WB 
1. LF F6, 27(R1) x xX xX 
2. LF F2, 45(R2) x Xx 


3. MULTF FO, F2, F4 Xx 


4. SUBF F8, F6, F2 Xx 
5. DIVF F10, FO, F6 x 
6. ADDF F6, F8, F2 X 


In continuare prezentam starea SR si a FPR în momentul definit mai sus, 
adica prima instructiune încheiata, a 2a în faza de executie iar celelalte aflate in 


faza de startare. 


Tabelul 3.5. Situatia statiilor de rezervare în prima instanta 


Stațiile de rezervare (SR) 


Tabelul 3.6. Starea registrilor generali in prima instanta 


Registrii generali FPR 


o [mon [roaz] [ae [anor [MUL 
sus [oa | oa | nu [oa | oA | oa | 


Din aceste structuri de date implementate in hardware, rezulta de exemplu ca 
SR ADDI urmeaza sa lanseze în executie instructiunea SUBF F8, F6, F2. Valoarea 
primului operand (F6) se afla deja în câmpul Vj unde a fost memorata & pe 
magistrala CDB ca urmare a terminarii executiei primei instructiuni. Evident ca 
rezultatul acestei instructiuni a fost preluat de pe CDB în registrul F6 dar si în 
bufferul LB1. Al 2-lea operand al instructiunii SUBF nu este înca disponibil. 
Câmpul de TAG Qk arata ca acest operand va fi generat pe CDB cu "adresa" 
LOAD? (LB2) si deci aceasta SR va prelua operandul in câmpul Vk de îndata ce 
acest lucru devine posibil. Preluarea acestui operand se va face de catre toate SR 
care au un câmp de TAG identic cu LOAD2 (LB2). 

Sa consideram de exemplu ca latenta unitatilor ADD este de 2 impulsuri de 
tact, latenta unitatilor MUL este de 10 impulsuri de tact pentru o inmultire si 
respectiv 40 impulsuri de tact pentru o operatie de impartire. "Starea" secventei 
anterioare in tactul premergator celui in care instructiunea MULTF va intra in faza 
WB va fi urmatoarea: 

Start Executie WB 


1. LF F6, 27(R1) x x x 


2. LF F2, 45(R2) x x xX 

3. MULTF FỌ, F2, F4 x X 

4. SUBF F8, F6, F2 x x x 

5. DIVF F10, FO, F6 x 

6. ADDF F6, F8, F2 x x x 

În acest moment, starea statiilor de rezervare si a setului de registri generali 


va fi cea prezentata în tabelele 3.7 respectiv 3.8: 


Tabelul 3.7. Situatia statiilor de rezervare în a doua instanta 


Stațiile de rezervare (SR) 


Tabelul 3.8. Starea registrilor generali în a doua instanta 


Regiştrii generali FPR 


De remarcat ca algoritmul a eliminat hazardul WAR prin registrul F6 între 


instructiunile DIVF si ADDF si a permis executia Out of Order a acestor 


instructiuni, in vederea cresterii ratei de procesare. Cum prima instructiune sa 
încheiat, câmpul Vk aferent SR MUL2 va contine valoarea operandului 
instructiunii DIVF, permitând deci ca instructiunea ADDF sa se încheie înaintea 
instructiunii DIVE. Chiar daca prima instructiune nu sar fi încheiat, cîmpul Qk 
aferent SR MUL2 ar fi pointat la LOADI si deci instructiunea DIVE ar fi fost 
independenta de ADDF. Asadar, algoritmul prin "pasarea" rezultatelor in SR de 
îndata ce acestea sunt disponibile, evita hazardurile WAR. Pentru a pune în 
evidenta întreaga "forta" a algoritmului în eliminarea hazardurilor WAR si WAW 
prin redenumire dinamica a resurselor, sa consideram bucla urmatoare: 
LOOP: LF FO, O (RI) 
MULTE F4, FO, F4 
SD 0 (R1), F4 
SUB RI, RI, #4 
BNEZ R1, LOOP 
Considerând o unitate de predictie a branchurilor de tip "branch-taken", 2 
iteratii succesive ale buclei se vor procesa ca mai jos (tabelele 3.9): 


Start Executie WB 


LF FO, 0 (R1) x x 
MULTE F4, FO, F2 x 
SD 0 (R1), F4 x 


LF FO, 0 (R1) x x 


MULTF F4, FO, F2 x 


SD 0 (R1), F4 x 


Tabelul 3.9. Contextul procesorului aferent buclei de program 


Stațiile de rezervare (SR) 


_sB1 | 5B2 | 
MUL2 


Se observa o procesare de tip "loop unrolling" ("netezirea buclei”) prin 
hardware. Instructiunea LOAD din a 2-a iteratie se poate executa înaintea 
instructiunii STORE din prima iteratie întrucât adresele de acces sunt diferite în 
câmpurile din buffere. Ulterior si instructiunile MULTE se vor putea suprapune în 
executie. De remarcat deci hazardul de tip WAW prin FO între instructiunile de 
LOAD s-a eliminat cu ajutorul SR si a bufferelor SB si LB. Arhitectura Tomasulo 


are deci avantajele de a avea logica de detectie a hazardurilor distribuita si prin 


redenumire dinamica a resurselor, elimina hazardurile WAW si WAR. Acest lucru 
este posibil pentru ca resursele tip sursa folosite si aflate in starea "BUSY", nu se 
adreseaza ca nume de registri ci ca nume de unitati de executie ce vor produce 
aceste surse. In schimb, arhitectura este complexa, necesitand deci costuri ridicate. 
Este necesara o logica de control complexa, capabila sa execute cautari / memorari 
asociative cu viteza ridicata. Având în vedere progresele mari ale tehnologiilor 
VLSI, variante usor îmbunatatite ale acestei arhitecturi se aplica practic în toate 
procesoarele superscalare actuale (pentru reducerea conflictelor, se folosesc mai 
multe busuri de tip CDB). 

Acest mecanism de forwarding din arhitectura lui Tomasulo, are meritul de a 
reduce semnificativ din presiunea la "citire" asupra setului general de registri 
logici, speculând dependentele RAW între instructiuni. Dezvoltari interesante ale 


arhitecturii Tomasulo sunt prezentate în [Pat85]. 


3.4. O ARHITECTURA REPREZENTATIVA DE PROCESOR 
SUPERSCALAR 


Având în vedere ideile de implementare a executiilor multiple din arhitectura 
lui 'Tomasulo, o arhitectura superscalara reprezentativa este prezentata în figura 3.6. 
Prin SR am notat statiile de rezervare aferente unitatilor de executie ale 
procesorului. Acestea implementeaza printre altele bufferul "instruction window" 


necesar procesoarelor superscalare cu executie Out of Order. Numarul optim de 


locatii al fiecarei SR se determina pe baza de simulare. 

Desi performanta maxima a unei asemenea arhitecturi ar fi de 6 
instructiuni/ciclu, in realitate, bazat pe simulari ample, s-a stabilit ca rata medie de 
executie este situata între F2 instructiuni / ciclu [Joh91]. În sub 1% din cazuri, 
masurat pe benchmark-uri nenumerice, exista un potential de paralelism mai mare 
de 6 instructiuni / ciclu în cazul unei arhitecturi superscalare "pure". Aceasta se 
datoreaza în primul rând capacitatii limitate a bufferului de prefetch care constituie 
o limitare principiala a oricarui procesor, exploatarea paralelismului între 
instructiuni fiind limitata de capacitatea acestui buffer. În tehnologia actuala acesta 
poate memora între 8 - 64 instructiuni, capacitati mai mari ale acestuia complicând 
mult logica de detectie a hazardurilor RAW dupa cum am aratat (vezi paragraful 


3.1). Prezentam pe scurt rolul modulelor componente din aceasta schema tipica. 


DECODIFICATOR 


SET BUFFER 
REGISTRI REORDONARE 
0 
= = 


| SR | 


Figura 3.6. Arhitectura tipica a unui procesor superscalar 


Decodificatorul plaseaza instructiunile multiple în SR- urile corespunzatoare. 
O unitate functionala poate starta executia unei instructiuni din SR imediat dupa 
decodificare daca instructiunea nu implica dependente, operanzii îi sunt diponibili 
si daca unitatea de executie este libera. În caz contrar, instructiunea asteapta în SR 
pâna când aceste conditii vor fi îndeplinite. Daca mai multe instructiuni dintr-o SR 
sunt simultan disponibile spre a fi executate, procesorul o va selecta pe prima din 
secventa de instructiuni. 

Desigur ca este necesar un mecanism de arbitrare în vederea accesarii CDB 
de catre diversele unitati de executie (UE). În vederea cresterii eficientei, deseori 


magistralele interne sunt multiplicate. Prezentam în fig. 3.7 circulatia informatiei 


într-o structura superscalara puternica, similara cu cea implementata la 
microprocesorul Motorola MC 88110. Setul de registri generali (FILE) este 
multiplicat fizic, continutul acestor seturi fizice este identic însa in orice noment. 
Am considerat ca UE- urile contin si statiile de rezervare aferente. Din acest motiv, 
având în vedere mecanismul de "forwarding" implementat, comunicatia între UE si 


CDB s-a considerat bidirectionala. 


BUFFER 
REORDONARE 


Figura 3.7. Multiplicarea magistralelor si a seturilor de registri 
Exista 3 categorii de busuri comune si anume: busuri rezultat (RB), busuri 
sursa (SB) si busuri destinatie (CDB). N corespunde numarului maxim de 
instructiuni care pot fi lansate simultan în executie. Min (M, P) reprezinta numarul 


maxim de instructiuni care pot fi terminate simultan. Uzual se alege M = P. Exista 


implementate mecanisme de arbitrare distribuite în vederea rezolvarii tuturor 
hazardurilor structurale posibile pe parcursul procesarilor. 

Pe baza de simulare in [Jou94] se încearca stabilirea unei arhitecturi 
optimale. Astfel se arata ca pentru o rata de fetch si de executie de 4 instructiuni, 
procesarea optima din punct de vedere performanta/cost impune 7 busuri 
destinatie, 4 unitati de executie întregi si 8 statii de rezervare pentru unitatile 
LOAD / STORE. Pentru o asemenea arhitectura s-ar obtine o rata de procesare de 
2.88 instructiuni / tact, masurat însa pe benchmark-uri cu un puternic caracter 
numeric, favorizante deci (Livermore Loops). Ideea de baza este însa ca 
hazardurile structurale se elimina si aici prin multiplicarea resurselor hardware, 
deci fara pierderi de performanta. Gradul de multiplicare trebuie însa stabilit prin 
simulari ample ori prin metode teoretice. 

Bufferul de reordonare 

Bufferul de reordonare (RB - Reorder Buffer) este în legatura cu mecanismul 
de redenumire dinamica a registrilor în vederea executiei Out of Order precum si 
cu necesitatea implementarii unui mecanism precis de tratare a evenimentelor de 
exceptie( derute, devieri, întreruperi hard-soft, etc.). Acesta contine un numar de 
locatii care sunt alocate în mod dinamic rezultatelor instructiunilor. 

În urma decodificarii unei instructiuni, rezultatul acesteia este asignat unei 
locatii din RB, iar numarul registrului destinatie este asociat acestei locatii. În acest 


mod, registrul destinatie este practic redenumit printr-o locatie din RB. În urma 


decodificarii se creaza prin hard un "tag" care reprezinta numele unitatii de 
executie care va procesa rezultatul instructiunii respective. Acest tag va fi scris în 
aceeasi locatie din RB. Din acest moment, când o instructiune urmatoare face 
referire la respectivul registru pe post de operand sursa, ea va apela în locul 
acestuia valoarea înscrisa în RB sau, daca valoarea nu a fost înca procesata, tag-ul 
aferent locatiei. Daca mai multe locatii din RB contin acelasi numar de registru 
(mai multe instructiuni în curs au avut acelasi registru destinatie), se va genera 
locatia cea mai recent înscrisa (tag sau valoare). 

Este evident deja ca RB se implementeaza sub forma unei memorii 
asociative, cautarea facându-se dupa numarul registrului destinatie la scriere, 
respectiv sursa la citire. Daca accesarea RB se soldeaza cu miss, atunci operandul 
sursa va fi citit din setul de registri. În caz de hit, valoarea sau tag-ul citite din RB 
sunt memorate în SR corespunzatoare. Când o unitate de executie genereaza un 
rezultat, acesta se va înscrie în SR si în locatia din RB care au tag-ul identic cu cel 
emis de catre respectiva unitate. Rezultatul înscris într-o SR poate debloca anumite 
instructiuni aflate în asteptare. Dupa ce rezultatul a fost scris în RB, instructiunile 
urmatoare vor continua sa-l citeasca din RB ca operand sursa pâna când va fi 
evacuat si scris în setul de registri. Evacuarea (faza WB) se va face în ordinea 
secventei originale de instructiuni pentru a se putea evita exceptiile imprecise. 
Asadar, redenumirea unui registru cu o locatie din RB se termina în momentul 


evacuarii acestei locatii. 


Bufferul RB poate fi gestionat ca o memorie FIFO (First In First Out). În 
momentul decodificarii unei instructiuni, rezultatul acesteia este alocat în coada 
RB. Rezultatul instructiunii este înscris în momentul în care unitatea de executie 
corespunzatoare îl genereaza. Când acest rezultat ajunge în prima pozitie a RB, 
daca între timp nu au aparut exceptii, este înscris în setul de registri. Daca 
instructiunea nu s-a încheiat atunci când locatia alocata în RB a ajuns prima, 
bufferul RB nu va mai avansa pâna când aceasta instructiune nu se va încheia. 
Decodificarea instructiunilor poate însa continua atât timp cât mai exista locatii 
disponibile în RB. 

Daca apare o exceptie, bufferul RB este golit, procesorul bazându-se pe 
contextul memorat In Order în setul general de registri. Astfel, desi proceseaza Out 
of Order, procesorul superscalar implementeaza un mecanism de exceptii precise. 
Mecanismul este similar cu cel numit "history buffer" si prezentat în cadrul 
procesoarelor pipeline scalare. În general, capacitatea RB se stabileste pe baza 
simularii unei arhitecturi superscalare, pe diverse programe de test reprezentative 
(benchmark- uri). Se apreciaza bazat pe masurari si simulari laborioase pe o 
multitudine de benchmark-uri ca performanta unui procesor superscalar "pur" nu 


poate depasi în medie 2-3 instr. / tact [Joh91]. 


3.5. PROBLEME SPECIFICE INSTRUCTIUNILOR DE RAMIFICATIE ÎN 
ARHITECTURILE MEM 


Sa consideram o secventa de program care se executa astfel: 

PC=743644 : Il 

I2 

13 

14 

I5 (branch conditionat) 
PC=342234 : 16 

I7 

I8 

19 (branch conditionat) 

Daca am presupune ca BDS-ul este de 2 cicli, procesarea secventei de mai 
sus pe un procesor superscalar (VLIW) cu procesare In Order care poate aduce si 
executa maxim 4 instructiuni / ciclu, s-ar desfasura ca în tabelul 3.10. Se observa 
ca pentru a compensa BDS-ul de 10 instructiuni, ar trebui introduse în acesta 10 
instructiuni anterioare instructiunii I5 si care sa nu o afecteze. Acest lucru este 
practic imposibil, de unde rezulta ca asemenea metode sunt inefective pentru 
procesoarele superscalare. Din acest motiv predictia hardware a branch-urilor pe 
baza unui BTB sau a unei scheme corelate pe 2 nivele, este implementata deseori 
în aceste procesoare. Pentru ca metodele de predictie prezentate pe larg în Capitolul 
2 sa functioneze si în acest caz, sunt necesare câteva completari datorate aducerii si 


executiei multiple a instructiunilor [Joh91]. 


Tabelul 3.10. Efectul BDS-ului într-un procesor superscalar 


a om a w N 


Se va considera ca o locatie a memoriei cache de instructiuni contine 4 
câmpuri. Fiecare câmp la rândul sau va fi format din: codul instructiunii respective, 
tag-ul format din bitii de adresa cei mai semnificativi, indexul de succesor (IS) si 
indexul branch-ului în locatie (IBL). Subcâmpul IS indica urmatoarea locatie din 
cache- ul de instructiuni (I-Cache) predictionata a fi adusa si respectiv prima 
instructiune ce trebuie executata din cadrul acestei locatii. Subcâmpul IBL indica 
daca exista sau nu o instructiune de salt în locatia din cache si daca da, locul 
acesteia în cadrul locatiei. Pentru secventa anterioara de program, intrarile în 


memoria I-Cache se prezinta ca în figura 3.8 (IBL s-a exprimat în binar). 


Tag=74, 1S=3650, IBL=100 


Tag=34, IS=????, IBL=000 


Figura 3.8. Structura intrarilor I-Cache într-un procesor superscalar 

Asadar subcâmpul IS pointeaza spre prima instructiune care trebuie executata 
în cadrul unei locatii din cache, iar subcâmpul IBL spre o eventuala instructiune de 
salt din cadrul aceleiasi locatii, predictionata ca se va face. Adresa completa a 
instructiunii la care se face saltul este continuta în tabelele de predictie 
corespunzatoare. 

În continuare se vor prezenta câteva tehnici software utilizate în procesoarele 
superscalare si VLIW. Aceste alternative pot simplifica mult complexitatea 
hardware a procesorului. Dupa cum se va vedea, utilizarea unor optimizari 
software elimina necesitatea executiei Out of Order a instructiunilor, a bufferului 


"instruction window", redenumirii dinamice a registrilor, etc. 


3.6. OPTIMIZAREA BASIC-BLOCK-URILOR ÎN ARHITECTURILE 
MEM 


Ca si in cazul procesoarelor scalare, reorganizarea (scheduling) reprezinta 
procesul de aranjare a instructiunilor din cadrul unui program obiect astfel incat 
acesta sa se execute intr-un mod cvasioptimal din punct de vedere al timpului de 
procesare. Procesul de reorganizare a instructiunilor determina cresterea 
probabilitatii ca procesorul sa aduca simultan din cache-ul de instructiuni mai 
multe instructiuni independente. De asemenea asigura procesarea eficienta a 
operatiilor critice din punct de vedere temporal în sensul reducerii prin masacare a 
latentelor specifice acestor operatii. Se va aborda mai întâi problema optimizarii " 
basic block"-urilor. De remarcat ca schedulingul în procesoarele superscalare poate 
determina o simplificare substantiala a arhitecturii hardware aferenta acestora 


[Col95]. 


Se va analiza acum spre exemplificare urmatoarea secventa de program: 


II: ADD  RI,RII,RI2 

12: ADD  RI,RI,RI3 

13: SLL R2, R3, #4; R2<--R3 deplasat logic la stânga cu 4 poz. 
binare 

14: AND R2,RI,R2 

I5: ADD RI, R14, R15 

I6: ADD  RI,RI,RI6 

I7: ADD RI, R1, #6 


I8: LD RI, RI) 


19: LD R4, R4) 


110: ADD RI,R4RI 
111: OR  RI,RI,R2 
112: ST RI, R4 


Considerând un procesor superscalar care decodifica simultan 4 instructiuni 
si detine 4 unitati de executie (2 unitati ALU, o unitate LOAD / STORE si o unitate 
pentru deplasari / rotiri), procesul de executie al secventei anterioare s-ar desfasura 
ca în tabelul 3.11 (am presupus ca doar instructiunile LOAD au latenta de 2 cicli 


masina): 


Tabelul 3.11. Executia unui program neoptimizat pe un procesor superscalar 


DECODIFICARE EXECUȚIE WRITEBACK CICLU 
ALU1 ALU2 SHF LS R1 R2 


ono N 0 AALA we N = 


De remarcat ca rata de procesare a acestei secvente este de 12 instructiuni per 


ciclu, adica 1,1 instructiuni / ciclu ( s-a considerat procesare In Order din punct de 
vedere al ferestrelor de executie si respectiv Out of Order in cadrul unei ferestre de 
executie). Se observa ca paralelismul potential al secventelor de instructiuni I1 - 14 
respectiv I5 - 112 nu este exploatat. În continuare se va prezenta un algoritm de 
reorganizare în "basic block'-uri (unitati secventiale de program) în vederea unei 


executii cvasioptimale pe un procesor superscalar sau VLIW. 


3.6.1. PARTITIONAREA UNUI PROGRAM ÎN "BASIC-BLOCK"-URI 


Se are în vedere construirea grafului de control al unui program dat. 
Algoritmul de partitionare consta principial în urmatorii 2 pasi: 

1) Determinarea setului de lideri în cadrul programului. Se numeste lider 
prima instructiune dintr-un program, instructiunea destinatie a oricarei instructiuni 
de branch sau orice instructiune urmatoare unei instructiuni de branch. 

2) Partitionarea programului în unitati secventiale si construirea grafului de 
control. Fiecare unitate secventiala contine un singur lider si toate instructiunile de 
la acest lider pâna la urmatorul exclusiv. 

Se determina predecesorii imediati fata de o unitate secventiala de program. 
Poate fi un predecesor imediat al unei unitati secventiale date orice unitate 
secventiala care se poate executa înaintea unitatii date. 

Se determina succesorii unei unitati secventiale de program. Se numeste 


succesor al unei unitati secventiale de program orice unitate secventiala de program 


care poate sa se execute dupa executia celei curente. In figura de mai jos (Fig. 3.9) 
se da un exemplu de partitionare a unui program dat în "basic block'-uri si graful 


de control al programului. 


A; 
B; 
Do{ 
D; 
E; 
if (F) { 
G; 
H; 
) 
ELSE 4 
I; 
} 
J; 
K; 
L; 
} WHILE (C) 


Figura 3.9. Partitionarea unui program în basic-block-uri 


3.6.2. CONSTRUCTIA GRAFULUI DEPENDENTELOR DE DATE 
ASOCIAT 


Dupa cum se va vedea, în stabilirea unei secvente reorganizate de program în 
vederea unei procesari cvasioptimale pe un procesor superscalar sau VLIW, graful 


dependentelor de date aferent unei unitati secventiale de program, se va dovedi 


deosebit de util. Un arc în acest graf semnifica o dependenta RAW între cele 2 
stari. Instructiunile care utilizeaza date din afara unitatii secventiale de program se 
vor plasa în vârful grafului astfel încât în ele nu va intra nici un arc. Pentru o 
instructiune data se cauta în jos proxima dependenta RAW. Cu aceste reguli 
simple, graful dependentelor de date corespunzator secventei de program anterioare 


este prezentat mai jos (Fig. 3.10): 


Figura 3.10. Graful dependentelor de date asociat 


In stânga arcului este scrisa latenta operatiei respective. In dreapta arcului 
este scrisa latenta maxima a drumului masurata dintr-un vârf al arcului pâna în 


starea respectiva. Graful dependentelor specifica deci relatii de ordine între 


instructiuni absolut necesare executie i corecte a programului dat. 

Graful precedentelor 

Se obtine pe baza grafului dependentelor de date în baza faptului ca exista 
cazuri în care acesta poate sa nu cuprinda toate precedentele necesare unei corecte 
reorganizari. Altfel spus, acest graf nu pune în evidenta relatiile de precedenta 
stricta în lansarea în executie, impuse de catre dependentele de tip WAR respectiv 
WAW între instructiuni. 

De exemplu, între instructiunile I2 si 15 exista o dependenta de tip WAW, iar 
între I4 si I5 una de tip WAR. Aceste dependente ar obliga schedulerul sa 
proceseze [2 si 14 înaintea instructiunii 15. Si totusi aceste dependente (mai degraba 
conflicte de nume) între secventele I1 - I4 si respectiv I5-I10 pot fi eliminate prin 
redenumirea registrilor care determina dependentele WAR si WAW ( în cazul 
nostru registrul R1). Astfel, de exemplu, daca în cadrul secventei de instructiuni I1- 
14 se redenumeste registrul R1 cu un alt registru disponibil în acel moment (de ex. 
cu R5), atunci secventele I1 - I4 si respectiv I5 - 110 devin complet independente, 
permitând o procesare paralela mai accentuata. 

Redenumirea registrilor, ca si în cazul procesoarelor scalare, se poate face 
static, adica prin software în momentul compilarii, sau dinamic, prin hardware în 
momentul procesarii. Trebuie deci redenumiti acei registri care determina 
dependentele WAR si WAW între ramuri independente ale unitatii secventiale de 


program. Se arata ca redenumirea registrilor creste numarul registrilor utilizati si 


timpul de viata al unui registru. Prin timp de viata al unui registru se intelege 
numarul instructiunilor cuprinse între prima instructiune care actualizeaza 
respectivul registru si respectiv ultima instructiune care-l citeste. Asadar, 
redenumirea registrilor creaza dificultati alocarii registrilor. Redenumirea se poate 
face pe durata timpului de viata al registrului. 

Important este însa faptul ca prin redenumire, graful precedentelor devine 
inefectiv, singurul care impune precedente reale, fundamentale, fiind deci graful 
dependentelor de date prin dependentele RAW intre instructiuni. Precedentele 
impuse prin dependente WAR si WAW au fost puse în evidenta prin linii întrerupte 
în figura anterioara. (Fig.3.10) De asemenea, pentru o corecta executie trebuie 
respectata ordinea instructiunilor LOAD / STORE, asadar instructiunile 18 si 19 
trebuie sa preceada instructiunea 112. Aceasta ultima constrângere însa, nu 
introduce în cazul concret analizat precedente suplimentare în graful dependentelor 
de date. Aceasta problema -numita si analiza antialias - a fost detaliata în capitolul 


2i 


3.6.3. CONCEPTUL CAII CRITICE 


Calea critica a grafului dependentelor de date o reprezinta drumul cu latenta 
maxima, fiind deci reprezentata în exemplul analizat aici de secventa de 
instructiuni I5, 16, I7, 18, I10, I11 si I12. Latenta acestei cai este de 8 cicli. 


Conceptul caii critice este important deoarece el indica faptul ca dupa scheduling, 


profitând la maxim de paralelismul între instructiuni, programul se va putea 
executa în minimum 8 cicli, adica într-un timp egal œ latenta caii critice. Prin 
strategia sa, schedulerul va trebui ca în fiecare ciclu, pe cât posibil, sa execute câte 
o instructiune din calea critica încercând simultan sa suprapuna peste aceasta 
instructiune si alte instructiuni independente din program. 

Într-un procesor ipotetic având resurse infinite, schedulerul optim ar trebui 
pur si simplu sa urmeze calea critica, suprapunând peste operatiile de aici operatii 
din alte cai. În cazul aparitiei unui hazard WAW sau WAR între instructiuni 
trebuiesc redenumite registrele implicate. De exemplu în cazul anterior prezentat, 
simultan cu instructiunea I5 s-ar putea executa instructiunile Il, I3 si 19 în 
conditiile în care procesorul ar detine suficiente resurse hardware (2 unitati ALU, o 
unitate de shiftare si o unitate LOAD / STORE în acest caz). De asemenea, datorita 
hazardului WAW dintre I1 si I5, în instructiunea I1 ar trebui redenumit registrul RI 
cu un alt registru disponibil din setul de registri. Cum în practica un procesor nu 
detine totdeauna suficiente resurse în vederea executarii celor de mai sus, rezulta ca 
timpul de executie al programului reorganizat este mai mare sau cel mult egal cu 
latenta caii critice. 

O reorganizare optima ar însemna sa se simuleze executia tuturor variantelor 
posibile de programe reorganizate si sa se masoare ratele de procesare aferente, 
alegându-se varianta de program cu rata cea mai mare. Pentru programe mari acest 


deziderat ar implica uneori saptamâni sau chiar ani de procesare devenind deci 


prohibit [Joh91]. În practica se prefera algoritmi euristici bazati pe graful 
dependentelor, care dau rezultate apropiate de cele optimale, în schimb necesita 
timpi de executie acceptabili. Asadar problema optimalitatii teoretice a scheduling- 
ului, nu se pune din probleme de timp. În plus algoritmii euristici utilizati în 


practica dau rezultate bune. 


3.6.4. ALGORITMUL "LIST SCHEDULING" (LS) 


Este unul dintre cei mai reprezentativi algoritmi în acest sens, fapt pentru care 
va fi prezentat pe scurt. Timpul de executie este rezonabil întrucât algoritmul se 
executa într-o singura trecere prin graful dependentelor, generând în majoritatea 
cazurilor reorganizari optimale [Joh91,Cho95]. 

Algoritmul LS parcurge graful dependentelor asociat unitatii secvențiale de 
program de jos în sus. În fiecare pas se încearca lansarea în executie a 
instructiunilor disponibile. Dupa ce aceste instructiuni au fost puse în executie, 
instructiunile precedente devin disponibile spre a fi lansate în pasul urmator. 
Fiecarei instructiuni i se ataseaza un grad de prioritate egal cu latenta caii 
instructiunii. Daca apare un conflict la resurse hardware comune între 2 sau mai 
multe instructiuni, are prioritate instructiunea cu un grad de prioritate mai mare. 
Precizând ca initial se seteaza un contor de cicli la o valoare maxima, pasii 
algoritmului sunt urmatorii: 


1) Instructiunea cea mai prioritara dintre instructiunile disponibile în setul 


curent este lansata in executie daca nu necesita o resursa ocupata în acest ciclu. 

2) Daca o instructiune a fost pusa în executie în pasul 1, resursele utilizate de 
aceasta vor fi setate ca fiind ocupate pentru un numar de cicli egali cu latenta 
instructiunii. Pentru exemplul nostru se va considera latenta instructiunilor LOAD 
de 2 cicli, iar latenta celorlalte instructiuni de un ciclu. 

3) Daca instructiunea a fost lansata în executie în pasul | ea va fi stearsa din 
lista instructiunilor disponibile în acel ciclu. Daca instructiunea nu a fost lansata în 
executie datorita unui conflict, reorganizarea va continua cu o alta instructiune 
disponibila. 

4) Se repeta pasii +3 pâna când nu mai exista nici o instructiune disponibila 
în acest ciclu. 

5) Se decrementeaza contorul de cicli. 

6) Se determina urmatorul set de instructiuni disponibile. Precizam ca o 
instructiune este disponibila daca diferenta între numarul ciclului în care a fost 
lansata în executie instructiunea succesoare si numarul ciclului curent este egala cu 
latenta instructiuni. 

7) Daca setul determinat la pasul 6 este consistent se trece la pasul 1. În caz 
contrar, reorganizarea este completa. 

Aplicarea algoritmului pe graful din exemplul considerat genereaza 


urmatoarea ordine de executie a instructiunilor (tabelul 3.12). 


Tabelul 3.12. Ordinea de executie a instructiunilor în urma optimizarii 


apf ee 
o oa 
zen 


CECCO 
E E TI 


Executia instructiunilor pe un procesor superscalar In Order Issue cu 4 unitati 


de executie se va face ca în tabelul de mai jos (tab.3.13): 


Tabelul 3.13. Executia programului optimizat 


ALU1 ALU2 SHF LD/ST 


aon mm hw NGS = 
— 


De remarcat ca în ciclul 4 a existat un conflict structural între instructiunile 18 
si 19. Sa dat prioritate instructiunii 18 pentru ca are un grad de prioritate superior. 


Invers mar fi putut fi pentru ca 18 si 17 sunt dependente RAW, de unde rezulta 


necesitatea prioritizarii dupa latenta nodurilor respective. Pe aceasta secventa de 
program se obtine o rata de procesare de 12 / 8 = 1.5 instr./ciclu fata de doar 1.1 
instr. / ciclu cat era rata de procesare a variantei de program nereorganizate, 
executata pe acelasi procesor superscalar. 

O alta observatie foarte importanta este aceea ca schedulingul poate 
îmbunatati semnificativ gradul de utilizare al resurselor hardware, dupa cum de 
altfel se poate observa si în cazul analizat aici. O varianta de algoritm similar care 


însa ar parcurge graful de sus în jos, ar genera urmatoarea executie (tabelul 3.14): 


Tabelul 3.14. O alta posibila executie a programului optimizat 


ALU 1 ALU2 SHF LD/ST 


O N 0 nm hw N = 


Latenta instructiunii 18 si dependenta RAW între I8 si I10, au impus ca în 
ciclul 4 sa nu se execute nici o operatie. Performanta este însa si în acest caz de 1.5 
instr. / ciclu. Este evident ca performanta unui procesor superscalar de tip In Order 
Issue care proceseaza un basic-block reorganizat optimal, este mai buna decât 


performanta unui procesor superscalar Out of Order care proceseaza programul 


neoptimizat pentru ca in al doilea caz paralelismul intre instructiuni este limitat de 
capacitatea bufferului de prefetch (instruction window). 

În literatura sunt citate 2 variante principiale de realizare a reorganizarilor 
software, între care exista un compromis fundamental [Cha95, Joh91]. Prima este 
metoda postscheduling, care implica dupa compilare mai întâi alocarea registrilor, 
iar apoi reorganizarea propriu-zisa. În acest caz reorganizatorul este constrâns la 
niste false dependente datorita faptului ca alocatorul de registri reutilizeaza un 
registru cât mai mult posibil, rezultând un timp de viata mai mic al acestuia, ceea 
ce duce la false dependente de date care se rezolva de catre scheduler prin 
redenumirea registrilor (în exemplul nostru a fost necesara redenumirea registrului 
R1). A doua metoda se numeste prescheduling si presupune mai întâi realizarea 
reorganizarii codului obiect, iar apoi alocarea registrilor. În acest caz este posibil ca 
alocatorul de registri sa nu poata pastra toate variabilele in registri, deoarece 
schedulerul prin redenumire mareste timpul de viata al registrilor utilizati. 
Algoritmul LS pune la dispozitia structurii hard paralelismul la nivel de instructiuni 
dintr-un program, pe care structura respectiva îl exploateaza la maxim. 

În continuare vom aborda problema optimizarii globale a programelor pentru 


procesoarele cu executie multipla a instructiunilor. 


3.7. PROBLEMA OPTIMIZARII GLOBALE ÎN CADRUL 
PROCESOARELOR MEM 


În continuare vom prezenta câteva tehnici software legate de optimizarea 
programelor pentru procesoarele superscalare si VLIW. În paragraful precedent s- 
au prezentat câteva tehnici în vederea optimizarii "basic -block"-urilor (optimizare 
locala). Optimizarea "basic -block"-urilor aferente unui program nu implica în mod 
necesar optimizarea întregului program datorita problemelor legate de 
instructiunile de ramificatie. 

Reorganizarea programelor care contin branch-uri este mai dificila întrucât 
aici "mutarile" de instructiuni pot cauza incorectitudini ale programului reorganizat 
care ar trebui corectate. Aceasta optimizare se mai numeste si optimizare globala. 
Problema optimizarii globale este una de mare actualitate si interes, întrucât 
paralelismul la nivelul basic -block-urilor, dupa cum aratau înca din anii '70 pionieri 
ca Michael Flynn, este relativ scazut (2-3 instructiuni). Deoarece majoritatea 
programelor HLL sunt scrise în limbaje imperative si pentru masini secventiale cu 
un numar limitat de registre în vederea stocarii temporare a variabilelor, este de 
asteptat ca gradul de dependente între instructiunile adiacente sa fie ridicat [Fra92]. 
Asadar pentru marirea nivelului de paralelism este necesara suprapunerea executiei 
unor instructiuni situate în basic-block-uri diferite, ceea ce conduce la ideea 
optimizarii globale. 

Numeroase studii [Cho95,Cha95,Col95,Pot96] au aratat ca paralelismul 
programelor de uz general poate atinge în variante idealizate (resurse hardware 


nelimitate, renaming perfect, analiza antialias perfecta, etc.) în medie 50-60 


instructiuni simultane. De remarcat ca schedulerele actuale, cele mai performante, 
raporteaza performante cuprinse intre 3-7 instructiuni simultane. Se apreciaza ca 
realiste obtinerea in viitorul apropiat a unor performante de 10-15 instructiuni 
simultane bazat pe îmbunatatirea tehnicilor de optimizare globala. 

Problema optimizarii globale este una deschisa la ora actuala, având o natura 
NP - completa. Se prezinta în continuare în acest sens doar tehnica numita "Trace 
Scheduling", datorita faptului ca este oarecum mai simpla si mai clar documentata. 
Consider ca marea majoritate a tehnicilor de optimizare globala nu au înca o 
justificare teoretica foarte solida, bazându-se deseori pe o euristica dependenta de 
caracteristicile arhitecturii [Ebci86, Col95]. Ele au drept scop executia unei 
instructiuni cât mai repede posibil, prin mutarea instructiunilor peste mai multe 
basic- block-uri. Constrângerile sunt date în principal de resursele hardware 
limitate. Pentru claritate, se va considera în continuare ca instructiunile de salt nu 


contin BDS-uri. 


3.7.1. TEHNICA "TRACE SCHEDULING" (TS) 


Este atribuita cercetatorului american Joshua Fischer [Fis81, Joh91, Hen96], 
pe atunci la Universitatea din New York, S.U.A., care a implementat-o în cadrul 
calculatorului VLIW numit BULLDOG( 1986). O implementare mai veche a 
acestei tehnici a fost legata de optimizarea microprogramelor în arhitecturi 


microprogramate orizontal. 


Se defineste o cale ("Trace") într-un program ce contine salturi conditionate, 
o ramura particulara a acelui program legata de o asumare data a adreselor acestor 
salturi. Rezulta deci ca un program care contine n salturi conditionate va avea 22 
posibile cai (trace-uri). Asadar, o cale a unui program va traversa mai multe unitati 


secventiale din acel program. În figura urmatoare (Fig.3.11) se prezinta un program 


compus din 2 cai distincte, si anume TRACE] si TRACE2. 


TRACE1 TRACE2 


A; 
B; 
C; 
IF (D) { 
E; 
F; 
} 
ELSE { 
G; 
} 
H; 


Figura 3.11. Exemplu de trace-uri pe 0 secventa de program 
Tehnica TS este similara cu tehnicile de reorganizare in "basic block"-uri, cu 
deosebirea ca aici se va reorganiza o întreaga cale si nu doar un basic block. În 
esenta, ea se bazeaza pe optimizarea celor mai probabile cai în a fi executate. Spre 
exemplificare sa consideram o secventa de program C si secventa de program 
obiect obtinuta prin compilare: 


ali] =al[i +; 


if (a[ i] < 100) { 
count = count +1; 


*(b + sum) = *( b + sum) + al i ];} 


1: SLL  RI,i,2 

2: ADD RI,Rl,base a 

3: LD R2, (R1); a[i] 

4: ADD R2, R2, 1;a[i]+1 

5: ST R2, (R1); asignare af i ] 
6: CPLT RI, R2, 100; a[ i] < 100? 
T: JMPF R1, LABEL 

8: ADD count, count, 1 

9: ADD RI, base_b, s_off; adresa lui b[ sum] 
10: LD R3, (R1) 

11: ADD R3, R3, R2 

12: ST R3, (R1) 

LABEL: 


Pentru a putea aplica TS compilatorul trebuie sa aiba criterii rezonabile de 
predictie a salturilor conditionate, în vederea construirii cailor cu cea mai mare 
probabilitate de executie. Exista aici o mare experienta înglobata în aceste 
compilatoare [Cho95,Cha95,Joh91,Hen96]. În general, predictia software se face 


pe baza informatiilor rezultate din anterioara executia programului neoptimizat 


(profilings) sau a altor algoritmi euristici inglobati in compilator. 

Executia secventei anterioare pe un procesor superscalar care decodifica 4 
instructiuni simultan si detine 5 unitati de executie se va face ca in tabelul 3.15. S-a 
considerat ca saltul conditionat nu se va face si ca procesorul executa In Order. 

Tabelul 3.15. Executia trace-ului neoptimizat 


DECODIFICARE EXECUTIE 
0 11 12 13 ALU1 ALU2 SHF LS BRN CICLU 


Datorita paralelismului limitat al acestei secvente se va obtine o rata medie de 
executie de doar o instr. / ciclu. Graful de control al acestei secvente este complus 


din doar 2 basic block-uri ca în figura 3.12. 


TRACE 


Figura 3.12. Graful de control aferent secventei de optimizat 


WAW/{R1) 


iis) es = 


Figura 3.13. Graful dependentelor pentru trace-ul considerat 


Se va considera ca programul compilator a ales calea prin care saltul nu se 
face spre a fi optimizata. Asadar, instructiunea de salt va fi tratata în acest caz ca 
oricare alta. Graful precedentelor de date asociat secventei anterioare de program 
este prezentat în fig. 3.13. Pentru a elimina dependentele WAR si WAW între cele 
2 ramuri paralele, vom redenumi R1 cu un alt registru disponibil (RS1) pe ramura 
9, 10, 11, 12. De remarcat ca aceasta problema se datoreaza alocatorului de registri 
din cadrul compilatorului. Aplicând acum algoritmul LS pe graful dependentelor 
de date aferent caii respective, obtinem urmatoarea ordine inversa de executie (v. 


tabelul 3.16). 


Tabelul 3.16. Ordinea de executie in urma optimizarii 


NOD } PRIORITATE 
127774? 
5/6, 6/6, 1176 


Asadar, executia se va face în 7 cicli ca mai jos: 


DI 1: SLL RI1,i,2 
2)2 2: ADD RI, R1, base_a 
3)3,9 3: LD R2, (R1) 
9)10 9: ADD RSI, base_b, s_off 
5)4,8 10: LD R3, (RS1) 
6)5,6,11 4: ADD  R2,R2,1 
7)12,7 8: ADD count, count, 1 

3: ST R2, (R1) 

6: CPLT RI, R2, 100 

11: ADD R3, R3, R2 

12: ST R3, (RS1) 

T JMPF R1, LABEL 


LABEL: 


Asadar prin suprapunerea operatiilor din cele 2 basic block-uri s-a obtinut o 
rata de procesare de 1.71 instr. / ciclu. Problema care apare însa este: ce se 
întâmpla daca saltul se face ? Raspunsul ar consta în utilizarea unor coduri de 
compensatie pentru predictiile incorecte. Tehnica TS presupune mutarea 
instructiunilor dintr-un basic block în altul si asta presupune anumite compensatii 
în vederea pastrarii corectitudinii programului reorganizat. Prezentam mai Jos 
compensatiile necesare atunci când o instructiune e mutata dintr-un basic block 


într-unul succesor respectiv predecesor (v. fig.3.14). 


Cod Original Migrare spre Migrare spre 
succesor [C, F) precedent (E, H) 


anulare E; 
G; 
H; 


Figura 3.14. Compensatii la migrarea instructiunilor dintr-un basic-block în altul 


În exemplul prezentat am avut o migrare a îtregului bloc $12 în blocul 


precedent 17, deci compilatorul va trebui sa introduca in al 2-lea bloc instructiuni 
de compensare in vederea anularii unor operatii, absolut necesare atunci cand saltul 


se face, ca mai jos: 


1: SLL R1,i,2 

2: ADD RI,Rl,base a 
3: LD R2, (RI) 

9: ADD RSI, base_b, s_off 
10: LD R3, (RSI) 

4: ADD R2, R2, 1 

8: ADD count, count, 1 
5: ST R2, (R10) 

6: CPLT RI, R2, 100 
11: ADD RS3, R3, R2 
12: ST RS3, (RS1) 

T: JMPF RI, C2 

CI: JMP LABEL 

C2: SUB count, count, 1 
C3: ST R3, (RS1) 
LABEL: 


În vederea anularii operatiei *(b+sum) = *(b+sum) + a[ i ] în cazul în care 


saltul se face, s-a introdus de catre compilator linia C3. Pentru ca aceasta anulare sa 


fie posibila a fost necesara redenumirea registrului R3 cu un altul disponibil (RS3 
aici) în instructiunile I11 si 112. Altfel, instructiunea I11 ar fi alterat R3 si deci 
anularea asignarii variabilei *(b+sum) în memorie ar fi fost imposibila. De 
remarcat similitudinea între corectiile soft si tehnicile hardware de executie 
speculativa prin care se redenumesc dinamic resursele procesorului. În [Joh91], se 
prezinta o serie de caracteristici arhitecturale cu scopul facilizarii implementarii 
tehnicii TS. Compensarea este eficienta numai daca ciclii suplimentari introdusi 
prin aceasta nu depasesc numarul ciclilor eliminati prin tehnica TS. O compensare 
eficienta presupune: 

- O acuratete ridicata a predictiei branch-urilor de catre compilator, obtinuta 
prin statistici rezultate din rularea programului. În acest sens programele numerice 
se preteaza mai bine la TS decât cele de uz general. 

- Procentaj relativ scazut al instructiunilor de ramificatie din program. 

- Codurile de compensatie sa fie posibile si fezabile. 

- Paralelism hardware pronuntat în vederea procesarii codurilor de 
compensare cu introducerea unui numar minim de cicli suplimentari. 

Într-un program dat, reorganizatorul selecteaza caile pentru scheduling, 
utilizând tehnici de predictie software. Pentru început se aplica algoritmul TS 
pentru calea cea mai probabila de a fi executata. Pe timpul acestui proces se vor 
adauga coduri de compensare. Apoi se selecteaza urmatoarea cale considerata cea 


mai probabila. Aceasta va fi de asemenea reorganizata prin tehnica TS. 


Reorganizarea se refera inclusiv la posibilele coduri compensatoare introduse & 
catre procesul anterior de reorganizare. Algoritmul TS se va repeta pentru fiecare 
cale in parte. Pentru limitarea timpului de reorganizare, referitor la caile mai putin 
frecvente in executie, se poate renunta la optimizarea globala in favoarea 
optimizarii exclusiv a basic block-urilor componente prin algoritmul LS. Nu exista 
inca criterii clare care sa stabileasca momentul in care optimizarea TS sa fie 
abandonata. 

O situatie oarecum ironica este legata de optimizarea programelor pentru 
procesoare superscalare datorita faptului ca in acest caz logica hardware de lansare 
în executie a instructiunilor va relua in mod redundant cautarea instructiunilor 
independente. Aceasta operatie este inutila fiind realizata anterior de catre 
optimizatorul software. Din acest motiv, acesta ar trebui sa marcheze grupele de 
instructiuni paralelizate, astfel încât hardware-ul sa nu mai reia inutil aceasta 
operatie. Într-un asemenea context, procesarea Out of Order a instructiunilor — 
caracteristica majora si complexa a multor procesoare superscalare — apare ca fiind 
complet inutila. Este înca o dovada a faptului ca paradigma procesarii 
instructiunilor trebuie sa fie una relativ simpla, dar în acelasi timp nu mai simpla 
decât este necesar în virtutea unor principii de eficienta, flexibilitate si 


compatibilitate. 


3.8. OPTIMIZAREA BUCLELOR DE PROGRAM 


Este foarte importanta pentru ca in buclele de program se pierde cea mai 
mare parte a timpului de executie aferent respectivului program, dupa regula 
binecunoscuta care afirma ca " 90% din timp executa cca. 10% din program”. Iata 


de ce optimizarea buclelor reprezinta o preocupare esentiala la ora actuala. 


3.8.1. TEHNICA "LOOP UNROLLING" 


Pentru ilustrarea principiului de optimizare, sa consideram urmatoarea bucla 
de program: 
for (îi =0; i< 64; i++) { 
sum += ali]; 
} 
Din compilarea acestei bucle rezulta urmatoarea secventa de program obiect 
tip RISC: 
LOOP: 1:LD RI, (a_ptr) 
2:ADD a_ptr, a_ptr, 4 
3:CLT count, a_ptr, end_ptr 
4:ADD sum, sum, Rl 
5:JMPTcount, LOOP 
Executia a doua iteratii succesive pe un procesor superscalar "in order issue" 


se va desfasura ca in tabelul de mai jos (tabelul 3.17). 


Tabelul 3.17. Executia buclei neoptimizate 


S-a considerat ca procesorul aduce 4 instructiuni simultan si detine 5 unitati 
de executie distincte (BRN - unitate de executie a instructiunilor de ramificatie). Se 
remarca faptul ca in acest caz rata de procesare este de 1.25 instr./ciclu sau altfel 
spus de 0.25 bucle/ciclu. Dupa aplicarea tehnicii Loop Unrolling [Hen96,Vin96, 


Joh91] de 2 ori secventa anterioara devine: 


LOOP: 1: LD RI, (a_ptr) 
2: ADD a_ptr, a_ptr, 4 
3: ADD sum, sum, R1 
4: LD R1, (a_ptr) 
5: ADD a_ptr, a_ptr, 4 
6: ADD sum, sum, R1 
AS CLT count, a_ptr, end ptr 
8: JMPT count, LOOP 


Reorganizând basic block-ul precedent prin metoda LS anterior descrisa, 


obtinem urmatoarea secventa de program: 
LOOP: 1: LD RI, (a_ptr) 


2: ADD a _ptr,a_ptr,4 


4: LD R2, (a_ptr) 

5: ADD a_ptr, a_ptr, 4 

T: CLT count, a_ptr, end_ptr 
3: ADD sum, sum, R1 

6: ADD sum, sum, R2 

8: JMPT count, LOOP 


Executia acestei bucle pe acelasi procesor superscalar se va face ca în tabelul 


3.18: 


Tabelul 3.18. Executia buclei optimizate 


ALU1 ALU2 SHF LS BRN CICLU 


S-a obtinut astfel o rata medie de procesare de 2 instr. / ciclu sau 0.5 bucle / 
ciclu, deci practic performanta sa dublat fata de exemplul precedent. Se pune 
problema: ce se întâmpla daca numarul de iteratii este necunoscut în momentul 
compilarii ? Pentru aceasta sa consideram secventa de mai jos: 


for G=0; i<n; i++) { 


sum +=ali]; 


} 


Aceasta secventa va fi compilata tinand cont si de aplicarea tehnicii LU ca 


mai jos: 

LOOP: 1: LD RI, (a_ptr) 
2: ADD a _ptr,a_ptr,4 
3: ADD sum, sum, R1 
4: CLT count, a_ptr, end ptr 
5: JMPF count, EXIT 
6: LD RI, (a_ptr) 
T: ADD a_ptr, a_ptr, 4 
8: ADD sum, sum, R1 
9: CLT count, a_ptr, end_ptr 
10: JPMT count, LOOP 

EXIT: 


Graful de control corespunzator acestei secvente este prezentat in figura 3.15. 


E 


| Graful de 


control 


Figura 3.15. Graful de control asociat buclei netezite 


Asadar, în astfel de cazuri dupa aplicarea tehnicii LU se obtine o cale formata 
din doua sau mai multe basic block-uri concatenate. Pentru optimizare se poate 
aplica algoritmul TS asupra grafului de control, dar aceasta poate complica si 


reduce sever eficienta tehnicii loop unrolling. 


3.8.2. TEHNICA "SOFTWARE PIPELINING" 


Tehnica software pipelining (TSP) este utilizata în reorganizarea buclelor de 
program astfel îcât fiecare iteratie a buclei de program reorganizata sa contina 
instructiuni apartinând unor iteratii diferite din bucla originala. Aceasta 
reorganizare are drept scop scaderea timpului de executie al buclei prin eliminarea 
hazardurilor intrinseci, eliminând astfel stagnarile inutile pe timpul procesarii 


instructiunilor. Prezentam principiul acestei tehnici bazat pe un exemplu simplu 


preluat din [Hen96]. Asadar sa consideram secventa de program urmatoare: 
LOOP: LD FO, 0(R1) 
ADD F4, FO, F2 
SD O(R1), F4 
SUBI RI, R1, #8 
BNEZ R1, LOOP 
Bucla realizeaza modificarea unui tablou de numere reprezentate in virgula 
mobila, prin adaugarea unei constante continuta in registrul F2 la fiecare dintre 
acestea. De remarcat ca hazardurile RAW între instructiunile I1, I2 respectiv I2, I3 
determina stagnari în procesarea pipeline a instructiunilor acestei bucle. Într-o 
prima faza TSP desfasoara, însa doar în mod simbolic, bucla în iteratii succesive 
eliminând actualizarea contorului si saltul înapoi. 
iteratia 1: LD FO, O(R1) 
ADD F4, FO, F2 
SD O(R1), F4 
iteratia i+1: LD FO, O(R1) 
ADD F4, FO, F2 
SD O(R1), F4 
iteratia i+2: LD FO, O(R1) 
ADD F4, FO,FI 


SD O(R1), F4 


În a doua faza, instructiunile selectate din cele trei iteratii se grupeaza in 


cadrul unei noi bucle ca mai jos: 


LOOP: SD O(R1), F4; memoreaza in M(i) 
ADD F4, FO, F2; modifica scalarul M(i-1) 
LD FO, - 16(R1); incarca elementul M(i-2) 


SUBI RI, R1, #8; 
BNEZ R1, LOOP; 

Observam ca prin pipeline-izarea instructiunilor din cadrul acestei bucle 
reorganizate s-au eliminat hazardurile anterioare si deci stagnarile implicate de 
catre acestea. Bucla se executa pe un procesor pipeline scalar în doar 5 impulsuri 
de tact, adica la viteza maxima asumând o predictie perfecta a saltului. De remarcat 
ca pe un procesor superscalar cu suficiente unitati de executie primele 3 
instructiuni s-ar putea executa simultan, ceea ce pe varianta originala a buclei nu se 
putea din cauza hazardurilor RAW. Asadar TSP este deosebit de eficienta pe 
procesoarele cu executie multipla a instructiunilor [Hen96,Fis81]. De multe ori este 
necesara interventia hardului sau a softului pentru eliminarea posibilelor hazarduri 
WAR care apar în cadrul buclei reorganizate. Totusi, pentru a fi functionala, bucla 
anterioara are nevoie de un preambul si respectiv un postambul. Preambulul 
necesar consta în executia instructiunilor din iteratiile 1 si 2 care nu au fost 
executate în cadrul buclei (LD - 1, LD - 2, ADD - 1). Analog, postambulul consta 


în executia instructiunilor care nu au fost executate în ultimele 2 iteratii (ADD - 


ultima, SD - ultimele 2 iteratii). 

Alaturi de tehnica LU, TSP este des utilizata in optimizarea buclelor de 
program. Spre deosebire de LU, aceasta consuma mai putin spatiu de cod. 
Frecvent, cele 2 tehnici sunt combinate în vederea cresterii performantei. Tehnica 
LU se concentreaza pe eliminarea codurilor redundante din cadrul buclelor 
(actualizari contoare, loop-uri). Bucla se proceseaza la viteza maxima doar pe 
parcursul iteratiilor desfasurate. TSP încearca în schimb, obtinerea unei viteze mari 


de executie pe întreg timpul procesarii buclei. 


3.9. ARHITECTURI CU TRANSPORT DECLANSAT 


Arhitecturile cu transport declansat (TTA - Transport Triggered 
Architectures) reprezinta o expresie limita a filosofiei RISC de exploatare a 
paralelismului instructiunilor. Aparitia lor (Universitatea din Delft, Olanda, 1992) a 
fost determinata de slabiciunile modelelor superscalar si VLIW, datorate în special 
gradului scazut de utilizare al resurselor hardware (unitati functionale, busuri 
interne, registri generali, etc) si complexitatii ridicate. 

Esenta TTA consta în separarea transportului datelor, de prelucrarea lor 
efectiva. Daca în arhitecturile conventionale (OTA-Operation Triggered 
Architectures) declansarea executiei unei operatii este initiata chiar de catre 
operatia (instructiunea) respectiva, în cadrul TTA aceasta declansare este initiata de 


catre un transport al operandului sursa într-un asa-numit registru trigger (T), atasat 


fiecarei unitati functionale din sistem. Un procesor TTA este compus din unitati 
functionale complet independente, interconectate printr-o asa-zisa retea de 
transport. Fiecare unitate functionala detine 3 registri: registrul operand (O), 
registrul trigger (T) si registrul rezultat (R). Transportul si inscrierea unui operand 
in registrul T, determina automat activarea unitatii functionale respective. Dupa 
cum am mai subliniat, un procesor TTA detine o singura instructiune (MOVE - 
transfer), care se poate executa conditionat pe 2 variabile de garda de tip boolean. 
Planificarea mutarilor între diversele unitati functionale (FU-Functional Unit) 
devine o sarcina software a compilatorului, nemaifiind integrata hardware în CPU 
ca în cazul clasic (OTA). Desigur ca unitatile functionale cu latenta mai mare de un 
tact pot fi pipeline-izate. De mentionat ca având o singura instructiune, logica de 
decodificare TTA practic nu exista. Cele doua figuri care urmeaza, 3.16 si 3.17, 
prezinta schema bloc de principiu a unui procesor TTA si respectiv pipeline-izarea 


unei anumite unitati functionale. 


FU flotant 


Set registri 
generali 


Unitate 
fetch 


Figura 3.16. Schema bloc a unei arhitecturi TTA 


Figura 3.17. Pipeline-izarea executiei in cazul unei arhitecturi TTA 
In continuare se prezinta 2 exemple: o "instructiune" de adunare si respectiv 


una de salt conditionat, implementate in TTA. 


ADD R3, R2, RI R1-->ADD_O, R2-->ADD_T (declansare) 
ADD_R-->R3 
if R2 = R3 goto Adr R2-->EQ_O, R3-->EQ_T 


EQ_R-->B1 (var. booleana) 
Bl Adr-->PC (executie conditionata) 

De remarcat ca sunt posibile mai multe transporturi, functie de largimea de 
banda a retelei de transport. Intervalul de timp dintre declansare si mutarea 
rezultatului trebuie controlat prin software astfel încât sa acopere latenta unitatii 
functional respective. 


Avantajele TTA 


Datorita simplitatii hardware a logicii de decodificare, control si planificare a 
instructiunii, procesoarele TTA permit frecvente de tact extrem de ridicate. Mai 
mult, separarea unitatilor functionale de reteaua de transport permite pipeline- 
izarea optimala a FU. Numarul de registri generali poate fi redus drastic datorita 
faptului ca trebuie stocate mai putine date temporare, multe dintre aceste date 
circulând direct între FU-uri, fara ca sa trebuiasca sa fie memorate într-un registru 
de uz general. Stagiile pipeline si registrii operanzi sunt utilizati pe post de registri 
temporari. Un rezultat produs de o FU, dar care nu poate fi utilizat direct de alt FU, 
poate fi lasat temporar în unitatea FU care l-a produs, daca acesta nu blocheaza alte 
rezultate anterior necesare, ale aceleiasi FU. Interesant, aici bypassing-ul 
(forwarding-ul) datelor este gestionat prin program, spre deosebire de procesoarele 
superscalare care realizeaza acest proces prin hardware (vezi Algoritmul lui 
Tomasulo). Spre exemplificare se considera doua instructiuni RISC dependente 
RAW, ca mai jos: 

ADD R3, R1, R2 R1-->ADD_O, R2-->ADD_T 

ADD R5, R3, R4 ADD_R->ADD_O, R4-->ADD_T, ADD_R-->R3 

ADD_R-->R5 

Se observa forwarding-ul realizat prin software (ADD_R-->ADD_O) si care 
optimizeaza executia cu un ciclu. Ca urmare se reduce presiunea la citire asupra 
setului de registri generali, analog cu mecanismul lui Tomasulo, doar ca aici prin 


software. Daca in continuare compilatorul constata ca timpul de viata aferent 


registrului R3 s-a incheiat, secventa anterioara devine mai simpla: 


ADD R3, R1, R2 R1-->ADD_O, R2-->ADD_T 
ADD R5, R3, R4 ADD_R-->ADD_O, R4-->ADD_T 
ADD_R-->R5 


Astfel se reuseste oprirea scrierii inutile in R3 si deci reducerea presiunii la 
scriere asupra setului de registri, lucru principial imposibil la nivelul procesoarelor 
OTA. 

Un alt avantaj al arhitecturilor TTA consta în flexibilitatea si scalabilitatea 
performantelor. Flexibilitatea consta într-o facila schimbare a functionalitatii, în 
concordanta cu aplicatia specifica. Scalabilitatea este determinata în principal de 
posibilitatea adaugarii de noi FU-uri, fara modifcari arhitecturale majore si de 
marirea capacitatii de transport în vederea cresterii gradului de paralelism. 
Divizarea operatiilor în transporturi elementare ofera un grad de paralelism mai fin, 
care determina posibilitati mai eficiente de scheduling static si deci performante 
superioare. 

Structurile TTA se preteaza foarte bine la proiectarea de procesoare dedicate 
unor aplicatii specifice (ASP-Application Specific Processor), parametrii FU si ai 
retelei de transport putând fi setati în acord cu aplicatia tinta. Desi mediatizate 
intens in literatura de specialitate, TTA-urile nu constituie în opinia mea, o 
paradigma novatoare a conceptului de procesor, reprezentând mai degraba o 


superclasa a arhitecturilor VLIW traditionale, cu deosebirea ca "sparg" atomicitatea 


instructiunii masina în asa-zise transporturi. Se permite astfel un control mai mare 
al executiei din partea compilatorului, cu posibilitati superioare de optimizare a 
codului. Performantele par remarcabile, depasind la nivel de simulare respectiv 
implementare cu FPGA-uri, cu 25-50% variante OTA echivalente (1-860). 

Cu toate ca la ora actuala aceste procesoare exista doar la nivel de prototip, 
firme comerciale serioase precum Intel si Hewlett Packard au initiat cercetari in 
domeniul TTA si deci n-ar fi deloc exclus ca unele idei sa se regaseasca in 


viitoarele microprocesoare avansate produse de aceste companii. 


3.10. EXTENSII ALE ARHITECTURILOR MEM BAZATE PE 
REUTILIZAREA DINAMICA A TRACE - URILOR DE INSTRUCTIUNI 


Din punct de vedere arhitectural se considera ca pana la ora actuala au existat 
3 generatii de (micro)procesoare de succes comercial dupa cum urmeaza: 

- generatia I caracterizata in principal prin executia secventiala a fazelor 
(ciclilor masina) aferente instructiunilor- masina. Pionierii acestei generatii sunt 
desigur inventatorii calculatorului numeric, inginerii Eckert si Mauchly, alaturi de 
cel care ulterior a teoretizat si a imbogatit conceptul, in persoana marelui om de 
stiinta american John von Neumann. 

- generatia a Il-a de procesoare, exploata paralelismul temporal aferent 
instructiunilor masina prin suprapunerea fazelor (pipeline). Primul reprezentant 


comercial a fost sistemul CDC-6600 (1964) proiectat de catre cel mai mare creator 


de calculatoare de înalta performanta si totodata unul dintre pionierii 
supercalculatoarelor, Seymour Cray. În anii '80, (micro)procesoarele RISC scalare 
au reprezentat aceasta generatie (J. Cocke de la IBM si D. Patterson de la Univ. 
Berkeley fiind doar doi dintre pionierii promotori ai acestor idei). 

- generatia a III-a, cea curenta, este caracterizata de procesarea mai multor 
instructiuni independente simultan prin exploatarea unui paralelism spatial la 
nivelul diverselor unitati functionale de procesare. Executia instructiunilor se face 
Out of Order, utilizând deci tehnici de reorganizare (dinamica sau statica) a 
instructiunilor în vederea minimizarii timpului global de executie. Pionierul acestei 
generatii a fost sistemul anilor '60 IBM-360/91 (printre proiectanti Anderson, 
Sparacio, Tomasulo, Goldschmidt, Earle, etc.). La ora actuala generatia aceasta 
este reprezentata prin microprocesoarele superscalare, VLIW, etc. 

De câtiva ani, în laboratoarele de cercetare (în special cele academice!) se 
întrezaresc câteva solutii privind caracteristicile majore ale urmatoarei decade, 
generatia a IV-a, pe care le vom analiza succint si fatalmente incomplet, în 
continuare. 

În ultimii ani, procesul œ proiectare al procesoarelor s-a modificat radical. 
Astazi, accentul principal nu se mai pune pe implementarea hardware, ci pe 
proiectarea arhitecturii. Se porneste de la o arhitectura de baza, care este modificata 
si îmbunatatita dinamic, prin simulari hborioase pe benchmark-uri reprezentative 


(Stanford, SPEC '92, '95, etc., pentru procesoarele de uz general). De exemplu, 


proiectantii firmei Intel, pentru procesorul Intel Pentium Pro (P6), au pornit de la o 
structura initiala care continea un pipeline cu 10 nivele, decodificator cu 4 
instructiuni / ciclu, cache-uri separate pe instructiuni si date de capacitate 32Ko 
fiecare si un total de 10 milioane tranzistori. Comportarea fiecarei componente a 
arhitecturii (efectul capacitatii primului nivel (L1) cache, numarul de nivele în 
pipeline, comportarea logicii de predictie a  salturilor, numarul de unitati 
functionale, etc.) a fost simulata soft prin rularea a aproximativ 200 benchmark-uri, 
cu peste 2 miliarde de instructiuni! Rezultatul final a impus un procesor cu un 
pipeline pe 14 nivele, 3 instructiuni decodificate în fiecare ciclu, 8Ko L1 cache de 
date si 8Ko L1 cache de instructiuni, cu un total de aproximativ doar 5.5 milioane 
tranzistoare integrate. 

Costul proiectarii este relativ mare si include în principal elaborarea unei 
arhitecturi dinamice, scrierea unui compilator, de C in general, pe arhitectura 
respectiva, scheduler (optimizator) pentru codul obiect, simulator puternic 
parametrizabil si complex, programe de interpretare a rezultatelor. De exemplu, 
microprocesorul MIPS-4000 s-a creat prin efortul a 30 de ingineri timp de 3 ani. 
Costul cercetarii-proiectarii a fost de 30 milioane dolari, iar cel al fabricarii efective 
de numai 10 milioane dolari. Numai pentru simulare si evaluare sau consumat 
circa 50.000 ore de procesare pe masini având performante de 20 MIPS [Vin97]. 

Oricum, arhitecturile cu executii multiple si pipeline-izate ale instructiunilor 


(superscalare, VLIW) dau deja anumite semne de "oboseala", limitarile fiind atât 


de ordin tehnologic cat si arhitectural [SV98]. Caracteristicile arhitecturale 
complexe implica tehnologii tot mai sofisticate, inca nedisponibile. Pe de alta parte, 
performantele lor cresc asimptotic pe actualele paradigme arhitecturale. Totusi, 
schimbari fundamentale sunt mai greu de acceptat in viitorul apropiat, in primul 
rând datorita compilatoarelor optimizate, având drept scop exploatarea mai 
pronuntata paralelismului la nivel de instructiuni, deoarece acestea sunt deosebit de 
complexe si puternic dependente de caracteristicile hardware. 

Exista deja opinii care arata ca arhitecturile superscalare si VLIW contin 
limitari fundamentale si care ar trebui analizate si eventual eliminate. Dintre aceste 
limitari amintim doar conflictele la resurse, datorate in principal centralzarii 
acestora. O idee interesanta bazata pe descentralizarea resurselor se prezinta în 
[Fra92] si are în vedere implementarea mai multor asa numite "Instruction 
Windows" (IW)- un fel de buffere de prefetch multiple în locul unuia singur si 
respectiv pe conceptul de multithreading. Lansarea în executie a instructiunilor se 
face pe baza determinarii celor independente din fiecare IW. Desigur ca trebuie 
determinate si dependentele inter- IW- uri. Ideea principala consta în executia 
paralela a mai multor secvente de program aflate în IW- uri diferite, bazat pe mai 
multe unitati functionale (multithreading). Astfel de exemplu, 2 iteratii succesive 
aferente unei bucle de program pot fi procesate în paralel daca sunt memorate în 
IW- uri distincte. O asemenea idee faciliteaza implementarea conceptelor de 


expandabilitate si scalabilitate, deosebit de utile în dezvoltarea viitoare a 


arhitecturii. 

În esenta, un procesor cu executii multiple ale instructiunilor este compus din 
2 mecanisme decuplate: mecanismul de aducere (fetch) a instructiunilor pe post de 
producator si respectiv mecanismul de executie a instructiunilor pe post de 
consumator. Separarea între cele 2 mecanisme (arhitectura decuplata) se face prin 
bufferele de instructiuni si statiile de rezervare, ca în figura 3.18. Instructiunile de 
ramificație si predictoarele hardware aferente actioneaza printr-un mecanism de 
reactie între consumator si producator. Astfel, în cazul unei predictii eronate, 
bufferul de prefetch trebuie sa fie golit macar partial iar adresa de acces la cache-ul 
de instructiuni trebuie si ea modificata în concordanta cu adresa la care se face 


saltul. 
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Figura 3.18. Arhitectura superscalara decuplata 


Pe baze statistice se arata ca un basic-block contine, pe programele de uz 
general, doar 4-5 instructiuni in medie, ceea ce inseamna ca rata de fetch a 
instructiunilor e limitata la cca. 5, aducerea simultana a mai multor instructiuni 


fiind inutila (fetch bottleneck). Desigur, aceasta limitare fundamentala ar avea 


consecinte defavorabile si asupra consumatorului, care ar limita principial si rata 
medie de executie a instructiunilor (IR - Issue Rate) la aceasta valoare. Progresele 
semnificative in algoritmii de lansare in executie impun însa depasirea acestei 
bariere. În acest sens, cercetarile actuale insista pe îmbunatatirea mecanismelor de 
aducere a instructiunilor prin urmatoarele tehnici: 

- predictia simultana a mai multor ramificatii / tact rezultând deci rate IR 
sporite (vezi conceptul Dual BTB, în cap. 3) 

- posibilitatea accesarii si aducerii simultane a mai multor basic- block-uri din 
cache, chiar daca acestea sunt nealiniate, prin utilizarea unor cache-uri multiport 

- pastrarea unei latente reduse a procesului de aducere a instructiunilor, în 
contradictie cu cele 2 cerinte anterioare. 

Alti factori care determina limitarea ratei de fetch a instructiunilor (FR- Fetch 
Rate) sunt: largimea de banda limitata a interfetei procesor - cache, missurile în 
cache, predictiile eronate ale ramificatiilor, etc. 

O paradigma interesanta, situata în prelungirea conceptului de 
superscalaritate si care poate constitui o solutie interesanta fata de limitarile mai 
sus mentionate, o constituie trace-procesorul, adica un procesor superscalar având 
o memorie trace-cache (TC). Ca si cache-urile de instructiuni (IC), TC este 
accesata cu adresa de început a noului bloc de instructiuni ce trebuie executat, în 
paralel cu IC. În caz de miss în TC, instructiunea va fi adusa din IC sau - în caz de 


miss si aici - din memoria principala. Spre deosebire însa de IC, TC memoreaza 


instructiuni contigue din punct de vedere al secventei lor de executie, in locatii 
contigue de memorie. O linie din TC memoreaza un segment de instructiuni 
executate dinamic si secvential in program (trace-segment). Evident, un trace poate 
contine mai multe basic-block-uri (unitati secventiale de program). Asadar, o linie 
TC poate contine N instructiuni sau M basic - block-uri, N>M, inscrise pe parcursul 


executiei lor. 
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Figura 3.19. Ansamblul trace-cache respectiv predictor multiplu 
Memoria TC este accesata cu adresa de inceput a basic-block-ului A, in 
paralel cu predictorul multiplu de salturi (vezi figura 3.19). Acesta, spre deosebire 
de un predictor simplu, predictioneaza nu doar adresa de început a urmatorului 


basic- block ce trebuie executat ci toate cele (M-1) adrese de inceput aferente 


urmatoarelor (M-1) basic- block-uri care urmeaza dupa A. Cei (M-1) biti generati 
de catre predictorul multiplu (taken/ not taken) selecteaza spre logica de executie 
doar acele blocuri din linia TC care sunt predictionate ca se vor executa ( in cazul 
acesta doar blocurile A si B intrucat predictorul a selectat blocurile ABD ca se vor 
executa, in timp ce in linia TC erau memorate blocurile ABC). 

O linie din TC contine [Pate97]: 

- N instructiuni in forma decodificata, fiecare având specificat blocul careia îi 
apartine. 

- cele 2M-1 posibile adrese destinatie aferente celor M blocuri stocate în linia 
TC. 

- un câmp care codifica numarul si "directiile" salturilor memorate în linia 
TC. 

Înainte de a fi memorate în TC, instructiunile pot fi predecodificate în scopul 
înscrierii în TC a unor informatii legate de dependentele de date ce caracterizeaza 
instructiunile din linia TC curenta. Aceste informatii vor facilita procese precum 
bypassing-ul datelor între unitatile de executie, redenumirea dinamica a registrilor 
cauzatori de dependente WAR (Write After Read) sau WAW (Write After Write) 
între instructiuni, etc., utile în vederea procesarii Out of Order a instructiunilor. O 
linie din TC poate avea diferite grade de asociativitate în sensul în care ea poate 
contine mai multe pattern-uri de blocuri, toate având desigur aceeasi adresa de 


început (A), ca în figura 3.20. 
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Figura 3.20. Selectia dintr-o linie trace-cache asociativa 


Asadar, segmentele începând de la aceeasi adresa (A), sunt memorate în 
aceeasi linie asociativa din TC. Ca si în structurile TC neasociative, verificarea 
validitatii liniei selectate se face prin compararea (cautarea) dupa tag. Deosebirea 
de esenta consta în faptul ca aici este necesara selectarea - în conformitate cu 
pattern-ul generat de catre predictorul multiplu - trace-ului cel mai lung dintre cele 
continute în linia respectiva. Este posibil ca aceasta selectie complexa sa dureze 
mai mult decât în cazul neasociativ si prin urmare sa se repercuteze negativ asupra 
duratei procesului de aducere a instructiunilor (fetch). Avantajul principal însa, 
dupa cum se observa si în figura, consta în faptul ca este probabil sa se furnizeze 
procesorului un numar de blocuri "mai lung” decât un TC simplu. Astfel de 


exemplu, daca pattern-ul real de blocuri executate este ABD, structura TC îl va 


furniza fara probleme, in schimb o structura TC neasociativa ce contine doar 
pattern-ul ABC, evident va furniza in aceasta situatie doar blocurile AB. 

Pe masura ce un grup de instructiuni este procesat, el este incarcat intr-o asa- 
numita "fill unit" (FU-unitate de pregatire). Rolul FU este de a asambla 
instructiunile dinamice, pe masura ce acestea sunt executate, intr-un trace-segment. 
Segmentele astfel obtinute sunt memorate in TC. Dupa cum am mai subliniat, este 
posibil ca inainte de scrierea segmentului in TC, FU sa analizeze instructiunile din 
cadrul unui segment spre a marca explicit dependentele dintre ele. Acest lucru va 
usura mai apoi lansarea in executie a acestor instructiuni întrucât ele vor fi aduse 
din TC si introduse direct în statiile de rezervare aferente unitatilor functionale. 
Unitatea FU se ocupa deci de colectarea instructiunilor lansate în executie, 
asamblarea lor într-un grup de N instructiuni (sau M blocuri) si înscrierea unui 
asemenea grup într-o anumita linie din TC. Exista desigur cazuri când FU poate 
crea copii multiple ale unor blocuri în TC. Aceasta redundanta informationala 
poate implica degradari ale performantei, dar pe de alta parte, lipsa redundantei ar 


degrada valoarea ratei de fetch a instructiunilor deci si performanta globala. 


intrări in TC (n=3) 
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Figura 3.21. Segmente asamblate pe timpul executiei unei bucle de program 


Se poate deci afirma ca un TC exploateaza reutilizarea eficienta a secventelor 
dinamice de instructiuni, reprocesate frecvent în baza a 2 motive de principiu: 
localizarea temporala a trace-ului si respectiv comportarea predictibila a salturilor 
în virtutea comportarii lor anterioare. Asadar, TC memoreaza trace-uri în scopul 
eficientizarii executiei programului si nu doar în scopul eficientizarii procesului de 
aducere al instructiunilor. Aceasta, pe motiv ca un segment din trace contine numai 
instructiuni care se vor executa. În cazul IC, daca într-un bloc exista o ramificatie 
efectiva, instructiunile urmatoare se aduceau inutil întrucât nu s-ar fi executat. 

Cum TC trebuie sa lucreze într-o strânsa dependenta cu predictorul de salturi, 
se impune îmbunatatirea performantelor acestor predictoare. Se pare ca solutia de 
viitor va consta într-un predictor multiplu de salturi, al carui rol principal consta în 


predictia simultana a urmatoarelor (M-1) salturi asociate celor maximum M blocuri 


stocabile in linia TC. De exemplu, pentru a predictiona simultan 3 salturi printr-o 
schema de predictie corelata pe 2 nivele, trebuie expandata fiecare intrare din 
structura de predictie PHT (Pattern History Table), de la un singur numarator 
saturat pe 2 biti, la 7 astfel de automate de predictie, ca in figura 3.22. Astfel, 
predictia generata de catre primul predictor (taken / not taken) va multiplexa 
rezultatele celor 2 predictoare asociate celui de al doilea salt posibil a fi stocat în 
linia curenta dn TC. Ambele predictii aferente primelor 2 salturi vor selecta la 
rândul lor unul dintre cele 4 predictoare posibile pentru cel de-al treilea salt ce ar 
putea fi rezident în linia TC, predictionându-se astfel simultan mai multe salturi. 
Daca predictorul multiplu furnizeaza simultan mai multe PC-uri, TC rezolva 
elegant si problema aducerii simultane a instructiunilor pointate de aceste PC-uri, 


fara multiportarea pe care un cache conventional ar fi implicat-o. 
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Figura 3.22. Predictor a 3 salturi succesive 


Asemenea predictoare multiple in conjunctie cu structuri de tip TC conduc 
practic la o noua paradigma a procesarii unui program masina numita "multiflow", 
caracterizata deci prin procesarea în paralel a mai multor basic -block-uri dintr-un 
program. În [Pate97] se prezinta o cercetare bazata pe simulare asupra conceptelor 
novatoare de TC si predictor multiplu, integrate într-o arhitectura superscalara 
extrem de agresiva dezvoltata la Universitatea din Michigan, SUA. În esenta, 
investigatia subliniaza urmatoarele aspecte: 

-cresterea gradului de asociativitate a TC de la 0 (mapare directa) la 4 
(asociativitate in blocuri de 4 intrari/ bloc) poate duce la cresteri ale ratei medii de 
procesare a instructiunilor de pana la 15% 

-capacitati egale ale TC si respectiv memoriei cache de instructiuni (64 ko, 
128 ko) conduc la performante cvasioptimale 

-asociativitatea liniei TC nu pare a conduce la cresteri spectaculoase de 
performanta 

-performanta globala fata de o arhitectura echivalenta, dar fara TC, creste cu 
circa 24%, iar rata de fetch a instructiunilor a instructiunilor în medie cu 92% 

În [Max98] se prezinta o alta tehnica de procesare, legata tot de reutilizarea 
dinamica a instructiunilor deja executate, posibil a fi folosita în conjunctie cu un 
trace cache. Aici însa, principalul scop urmarit consta în paralelizarea executiei 


unor instructiuni dependente RAW, bazat pe predictia valorilor registrilor utilizati 


de aceste instructiuni. Ideea originara apartine scolii de arhitectura calculatoarelor 
de la Universitatea din Wisconsin — Madison, mai precis cercetatorilor A. Sodani si 
G. Sohi care au introdus în 1997, la conferinta ISCA 97 tinuta la Denver, SUA, 
conceptul de reutilizare dinamica a instructiunilor. Autorii arata în primul rând ca 
reutilizarea unor instructiuni sau secvente de instructiuni este relativ frecventa si se 
datoreaza modului compact de scriere al programelor precum si caracteristicilor 
intrinseci ale structurilor de date prelucrate. Ideea de baza este ca daca o secventa 
de instructiuni se reia în acelasi “context de intrare”, atunci executia sa nu mai are 
sens fiind suficienta o simpla actualizare a “contextului de iesire”, în concordanta 
cu cel precedent. Daca arhitectura TC - dupa cum am aratat - actioneaza asupra 
depasirii unei limitari fundamentale asupra ratei de fetch a instructiunilor, aceasta 
noua inovatie arhitecturala va actiona asupra limitarii ratei de executie a 
instructiunilor. Reamintim ca aceasta rata de executie este fundamental limitata de 
hazardurile structurale implicate precum si de hazardurile RAW între instructiuni. 
Asadar, instructiunile reutilizate nu se vor mai executa din nou, ci pur si simplu 
contextul procesorului va fi actualizat în conformitate cu actiunea acestor 
instructiuni, bazat pe istoria lor memorata. 

În Sod 97 se analizeaza mai întâi daca gradul de reutilizare al 
instructiunilor dinamice este semnificativ si se arata ca raspunsul este unul 
afirmativ. Exista în acest sens 2 cauze calitative în primul rând faptul ca 


programele sunt scrise în mod generic, ele operând asupra unei varietati de 


date de intrare, iar in al 2-lea rand, 
In vederea scopului propus, pe parcursul procesarii instructiunilor, se 


wen 
1 


construiesc în mod dinamic asa-numite seturi de instructiuni. O instructiune se 


A kot 1 


adauga unui set notat cu S daca "i" depinde RAW de cel putin una dintre 


wen 
1 


instructiunile setului S. In caz contrar, instructiunea "1" va fi prima apartinând unui 
nou set. Practic, constructia acestor seturi implica generarea grafului dependentelor 


de date atasat programului, ca in secventa de mai jos preluata din [Max98] (vezi 


figura 3.23). 
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Figura 3.23. Constructia seturilor in vederea reutilizarii codurilor 
Dupa procesarea instructiunilor, seturile rezultate sunt inscrise in vederea 
reutilizarii într-un buffer special numit TDIS (Table of Dependent Instruction 
Sequences). O intrare in TDIS contine 3 parti principale: 
- partea IN, care memoreaza valorile operanzilor de intrare, adica aceia 


neprodusi prin secventa respectiva ci preluati din afara acesteia. 


- partea INSTRUCTION, contine adresele instructiunilor inserate in seturi. 

- partea OUT, ce contine numele registrilor destinatie aferenti unui set, 
precum si valorile acestora. 

Pentru exemplificare, secventa de program anterioara necesita un buffer 


TDIS cu doua intrari, ca mai jos (figura 3.24). 
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Figura 3.24. Structura TDIS la un moment dat 

Asadar, la fiecare aducere a unei noi instructiuni, PC-ul acesteia se compara 
cu adresa primei instructiuni din fiecare linie a TDIS. Apoi, continutul actual al 
registrilor procesorului este comparat cu cel al partii IN a TDIS. În caz de hit, 
secventa de instructiuni din TDIS poate fi reutilizata cu succes si cu eludarea 
tuturor hazardurilor RAW dintre aceste instructiuni. Executia acestor instructiuni 
va însemna doar actualizarea contextului procesorului în conformitate cu valorile 
OUT din TDIS. Prin urmare, reutilizarea instructiunilor prin acest mecanism va 
avea un efect benefic asupra timpului de procesare al instructiunilor. Considerând 
un procesor superscalar care poate aduce, decodifica si executa maximum 4 


instructiuni / ciclu, secventa anterioara se proceseaza ca în cele doua figuri 


urmatoare (3.25, 3.26). 
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Figura 3.26. Executia programului pe un procesor cu reutilizarea codurilor 
Se observa ca bufferul TDIS determina executia secventei prin reutilizarea 
instructiunilor în doar 4 cicli fata de 7 cicli câti ar fi fost necesari în cazul unei 
procesari clasice. Daca largimea de banda a decodorului de instructiuni ar fi fost de 


6 instructiuni în loc de 4, executia secventei sar fi redus la doar 3 cicli. Teste 


efectuate pe benchmark-urile SPEC 95 si prezentate in [Max98], au aratat ca intre 
17% si 26% dintre instructiunile acestor programe au putut fi reluate cu succes. 
Conceptul TDIS este eficient întrucât ca si în cazul utilizarii instructiunilor 
combinate [Vas93], se elimina necesitatea secventierii în executie a unor 
instructiuni dependente RAW. Mai mult, în opinia autorului, dintr-un anume punct 
de vedere, conceptul reutilizarii dinamice a secventelor dependente de instructiuni, 
violeaza oarecum celebra lege a lui G. Amdahl întrucât trece peste secventialitatea 
intrinseca a programului si proceseaza agresiv paralel chiar si în acest caz, prin 
“updating”. Este fara îndoiala posibil ca acest concept sa se cupleze favorabil cu 
cel de tip "trace cache" anterior prezentat si care actioneaza favorabil în special 
asupra limitarilor ratei de fetch a instructiunilor. 

În contextul urmatoarei generatii arhitecturale de microprocesoare de înalta 
performanta, cea de a 4-a, se întrevede de asemenea implementarea unor 
mecanisme de aducere de tip Out of Order a instructiunilor, în plus fata de cele deja 
existente în executia instructiunilor. Astfel de exemplu, în cazul unei ramificatii 
dificil de predictionat, pe durata procesului de predictie, procesorul poate sa aduca 
anticipat instructiunile situate începând cu punctul de convergenta al ramurilor de 
salt. Aceste instructiuni fiind independente de conditia de salt, pot fi chiar lansate 
în executie. Când predictia se va fi realizat sau pur si simplu când adresa destinatie 
a ramificatiei va fi cunoscuta, procesorul va relua aducerea instructiunilor de la 


adresa destinatie a ramificatiei. 


În viitorul apropiat, unitatea de executie va trebui sa lanseze spre unitatile 
functionale între 16 si 32 instructiuni în fiecare tact. Evident, executia 
instructiunilor se va face Out of Order, pe baza dezvoltarii unor algoritmi de tip 
Tomasulo [Tom67]. Statuile de rezervare aferente unitatilor de executie, vor trebui 
sa aiba capacitati de peste 2000 de instructiuni Pentru a evita falsele dependente de 
date (WAR, WAW), procesoarele vor avea mecanisme de redenumire dinamica a 
registrilor logici. Desigur, tehnicile de scheduling static vor trebui îmbunatatite 
radical pentru a putea oferi acestor structuri hardware complexe suficient 
paralelism Se estimeaza dingerea unor rate medii de procesare de 12-14 instr. / 
tact, considerând ca se pot lansa în executie maximum 32 instr. / tact. La ora 
actuala, cele mai avansate procesoare, cu un potential teoretic de 6 instr. / tact, 
ating în realitate doar 1.2-2.3 instr. / tact [Comp97]. 

Aceste rate mari de procesare, impun executia paralela a cca. 8 instructiuni 
Load/ Store. Aceasta implica un cache de date primar de tip multiport si unul 
secundar, de capacitate mai mare dar cu porturi mai putine. Miss-urile pe primul 
nivel, vor accesa al 2-lea nivel. Pentru a nu afecta perioada de tact a procesorului, 
este posibil ca memoria cache din primul nivel sa fie multiplicata fizic. De 
asemenea, în vederea îmbunatatirii performantei, viitoarele microprocesoare vor 
predictiona adresele de acces ale instructiunilor Load, asemenea predictiilor 
salturilor, permitând acestora sa se execute înainte de calculul adresei. 


Aceste noi arhitecturi, care executa trace-uri ca unitati de procesare, vor putea 


permite procesarea mai multor asemenea trace-uri la un moment dat, ceea ce 
conduce la conceptul de procesor multithreading. Asadar paralelismul la nivel de 
instructiuni (ILP- Instruction Level Parallelism) va fi inlocuit cu unul mai masiv, 
constituit la nivelul thread-urilor unei aplicatii (ILP- Thread Level Parallelism). În 
acest scop, arhitectura va trebui sa contina mai multe unitati de procesare a trace- 
urilor, interconectate. La aceasta, se adauga o unitate de control "high-level", în 
vederea partitionarii programului în thread-uri de instructiuni independente. Se 
poate ajunge astfel la o rata de procesare de mai multe trace-uri / tact fata de 
instructiuni / tact, metrica de performanta obisnuita a procesoarelor superscalare 
actuale. E posibil ca aceste TLP-uri sa acopere "semantic -gap'-ul existent între 
paralelismul la nivel de instructiuni si respectiv cel situat la nivelul programelor, 
mult mai masiv. O alta paradigma noua, oarecum asemanatoare, dar mai 
îndepartata probabil ca realitate comerciala, o constituie multiprocesoarele 
integrate într-un singur circuit, ca solutie în vederea exploatarii paralelismului 
masiv ("coarse grain parallelism"). Aceasta este încurajata si de anumite limitari 
tehnologice care ar putea afecta dezvoltarea arhitecturilor uniprocesor. 

Se estimeaza ca toate aceste idei arhitecturale agresive, sa poata fi 
implementate într-un microprocesor real, abia atunci când tehnologia va permite 
integrarea "on-chip" a 800 milioane -1 miliard de tranzistori, ceea ce va fi posibil în 
jurul anului 2010 (predictie "Semiconductor Industry Association" în 1996 


[Comp97]). La acest nivel de dezvoltare tehnologica va fi posibila de asemenea 


integrarea "on-chip" a memoriei DRAM, la un timp de acces de cca. 20 ns. Ideea 
este atragatoare pentru ca la aceeasi suprafata de integrare, o memorie DRAM 
poate stoca de cca. 30-50 de ori mai multa informatie decât o memorie SRAM pe 
post de cache. Se estimeaza ca într-o prima faza, un DRAM integrat de 96 MB va 
necesita 800 milioane de tranzistori ocupând cca 25% din suprafata circuitului 
(vezi pentru detalii http://Aram.cs.berkeley.edu/) 

În orice caz, se pare ca pentru a continua si în viitor cresterea exponentiala a 
performantei microprocesoarelor, sunt necesare idei noi, revolutionare chiar, pentru 
ca în fond paradigma actuala este, conceptual, veche de circa 15-20 de ani. Ar fi 
poate necesara o abordare integrata, care sa îmbine eficient tehnicile de scheduling 
software cu cele dinamice, de procesare hardware. În prezent, dupa cum a rezultat 
din cele prezentate pâna acum, separarea între cele 2 dordari este poate prea 
accentuata. În acest sens, programele ar trebui sa expliciteze paralelismul intrinsec 
într-un mod mai clar. Cercetarea algoritmilor ar trebui sa tina seama cumva si de 
concepte precum, de exemplu, cel de cache, în vederea exploatarii localitatilor 
spatiale ale datelor prin chiar algoritmul respectiv. Cunoastem putine lucruri despre 
ce se întâmpla cu un algoritm când avem implementate ierarhii de memorii pe 
masina fizica. Desigur, asta nu înseamna ca programatorul va trebui sa devina 
expert în arhitectura computerelor, dar nu o va mai putea neglija total daca va dori 
performanta. În noua era “post PC” spre care ne îndreptam, centrata pe Internet, 


fiabilitatea, disponibilitatea si scalabilitatea vor trebui sa devina criterii esentiale 


alaturi de performanta in sine, ceea ce implica iarasi necesitatea unei noi viziuni 
pentru arhitectul de computere. 

De asemenea, se poate predictiona o dezvoltare puternica în continuare a 
procesoarelor multimedia. Aplicatiile multimedia spre deosebire de cele de uz 
general, nu impun în mod necesar complicate arhitecturi de tip superscalar sau 
VLIW. Aceste aplicatii sunt caracterizate de urmatoalele aspecte care le vor 
influenta în mod direct arhitectura: 

-structuri de date regulate, de tip vectorial, cu tendinte de procesare identica a 
scalarilor componenti, care impun caracteristici de tip SIMD (Single Instruction 
Multiple Data), de natura vectoriala deci, a acestor procesoare; 

-necesitatea procesarii si generarii raspunsurilor în timp real; 

-exploatarea paralelismului la nivelul thread-urilor independente ale aplicatiei 
(codari / decodari audio, video, etc); 

-localizare pronuntata a instructiunilor prin existenta unor mici bucle de 
program si nuclee de executie care domina timpul global de procesare. 

Având în vedere cele expuse anterior, în urmatorul paragraf se prezinta 
succint caracteristicile procesarii vectoriale, cea care sta la baza acestor procesoare 


multimedia si a altor procesoare si coprocesoare specializate. 


3.11. PROCESAREA VECTORIALA 


Alaturi Œ procesarea pipeline, procesarea vectoriala este o tehnica deosebit 


de performanta nelipsita in implementarea procesoarelor componente ale 
supercalculatoarelor actuale. În esenta procesarea vectoriala [Sto93] reprezinta 
prelucrarea informatiei numerice sub forma de vectori. Ca si tehnica pipeline pe 
care o înglobeaza, procesarea vectoriala urmareste în principiu cresterea ratei de 
procesare la nivelul programului, fiind deci o tehnica de exploatare a paralelismului 
la nivelul datelor din program. De multe ori aceste arhitecturi vectoriale se 
întâlnesc în literatura sub numele de sisteme SIMD (Single Instruction Multiple 
Data). În continuare se vor prezenta pe scurt câteva elemente arhitecturale specifice 
acestui concept precum si problemele implicate de catre acestea. se va insista ca si 
pâna acum, pe problemele interfetei hardware-software, necesare întelegerii acestor 
arhitecturi de catre utilizator în vederea exploatarii lor prin software. Daca 
precedentele modele nu afectau viziunea programatorului HLL, modelul vectorial 
modifica acesasta viziune "independenta de masina" într-un mod agresiv, similar 
cu cel al sistemelor multiprocesor. 

Prin notiunea de vector se întelege un tablou (sir) constituit din elemente 
scalare de acelasi tip. În general elementele vectorilor sunt numere reprezentate în 
virgula mobila (semn, mantisa, caracteristica) pe mai multi octeti (de regula pe 4, 8 
sau 10 octeti conform standardelor IEEE). Prin lungimea vectorului întelegem 
numarul de elemente scalare ce formeaza vectorul. Dupa cum vom arata, eficienta 
maxima a procesarii se obtine atunci când numarul unitatilor de prelucrare din 


cadrul unitatilor de executie specializate, coincide cu lungimea vectorului. O alta 


caracteristica a unui vector îl constituie pasul vectorului, adica diferenta numerica 
dintre valorile adreselor de memorie la care se afla doua elemente scalare succesive 
din punct de vedere logic (VG), V(+1)) ale unui vector. În fine, lungimea 
scalarului, adica lungimea în octeti a unui element scalar inclus în vector, are 
importanta întrucât afecteaza performanta unitatilor scalare de executie. 

În conformitate cu tipul operanzilor pe care îi prelucreaza si respectiv cu tipul 
rezultatului pe care îl genereaza se obisnuieste clasificarea instructiunilor vectoriale 
(1), în patru categorii de baza si anume: 

- instructiuni de tipul Il: V -> V, V= multimea operanzilor vectori. De 
exemplu, o instructiune de complementare a unui vector. 

- instructiuni de tipul I2 : V -> S, S= multimea operanzilor scalari. De 
exemplu, determinarea elementului scalar minim / maxim al unui vector. 

- instructiuni de tipul I3 : VxV -> V, de exemplu instructiuni aritmetico / 
logice cu 2 operanzi vectori 

- instructiuni de tipul I4 : VxS -> V, de exemplu înmultirea unui vector cu un 
scalar. 

De remarcat ca o singura instructiune vectoriala specifica o multitudine de 
operatii scalare executate în paralel, fiind deci echivalenta cu o bucla de program 
executata de un procesor scalar. Întrucât o bucla de instructiuni scalare poate fi 
înlocuita cu o singura instructiune vectoriala, rezulta ca astfel se elimina multe 


dintre problemele generate de hazardurile specifice arhitecturilor pipeline (RAW - 


uri, ramificatii, analiza antialias, etc.). O alta caracteristica a masinilor vectoriale 
consta in faptul ca acestea pipelinizeaza procesarea pe elemente scalare ale 
vectorilor. De asemenea nu este greu de sesizat, ca procesarea vectorilor implica 
arhitecturi de memorie cu acces intretesut ("interleaving"), ceea ce implica 
avantajul ca latenta memoriei va afecta la nivel de operare vector si nu de operare 
scalar. O astfel de arhitectura este performanta de exemplu atunci cand se citesc 
mai multe cuvinte succesive (situate in blocuri de memorie succesive), începând cu 
o adresa putere a lui 2. Întrucât opereaza asupra vectorilor compusi din scalari 
reprezentati in virgula mobila, performanta absoluta masinilor vectoriale se 
exprima în general în MFLOPS (Mega FLotant Operation Per Second), spre 
deosebire de perfomanta procesoarelor scalare exprimata uzual în MIPS (Mega 
Instruction Per Second). 

Exista masini vectoriale de tip vector - registru si respectiv memorie - 
memorie. Masinile vector - registru au caracteristic faptul ca toate operatiile cu 
vectori, mai putin cele de LOAD / STORE, se executa între registrii vectoriali 
interni. Aceste masini, reprezinta deci o arhitectura analoaga arhitecturii LOAD / 
STORE din cadrul procesoarelor MEM. Masinile memorie - memorie, mai putin 
frecvente decât primele, se caracterizeaza prin faptul ca toate operatiile între 
vectori se executa memorie - memorie. O arhitectura vectoriala tipica este 


prezentata în figura 3.27. 
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Figura 3.27. Structura unei masini vector - registru 

Registrii vectoriali sunt de lungime fixa notata cu M, fiecare registru 
continând un singur vector. Unitatile functionale, sunt unitati de executie pipeline- 
izate care opereaza concurent asupra operanzilor vectori. Numarul de astfel de 
unitati este diferit de la un procesor la altul. Evident ca este necesara si o unitate de 
control speciala pentru detectia si controlul hazardurilor din cadrul unitatilor de 
executie pipeline. Unitatea LOAD / STORE, acceseaza vectorii din memoria 
principala. Se urmareste atingerea unei rate de transfer CPU memorie de un 


element / ciclu CPU, dupa depasirea latentei initiale a memoriei principale cu acces 


întretesut. În fine, mai exista si setul de registri scalari, necesari pentru executia 
proceselor scalare. 

Probleme în vectorizarea programelor. 

Prin notiunea de vectorizare a unui program scris într-un limbaj de nivel înalt, 
se întelege posibilitatea ca respectivul program sa fie compilat utilizându-se 
instructiuni masina vectoriale. Cum instructiunile se preteaza în general în 
compilarea buclelor de programe scrise în limbaje de nivel înalt, se pune indeosebi 
problema vectorizarii buclelor de program. Asadar, pentru ca o masina vectoriala 
sa fie viabila, trebuie ca programul compilator sa recunoasca daca o bucla de 
program este sau nu vectorizabila si daca este atunci sa genereze codul obiect 
corespunzator. Este evident ca exista bucle de program nevectorizabile, de ex. 
buclele recurente, precum secventa de mai jos : 

for i = 1 to 100 

X(+1) = XQ) + X (+1); 

Se pune deci problema, cum poate detecta compilatorul daca o bucla de 
program este ori nu este vectorizabila ? Dintre multele posibile raspunsuri la 
aceasta problema, in continuare prezentam doar unul, deosebit de simplu. Prin 
urmare, exista o dependenta de date care face o bucla nevectorizabila daca exista 2 
indici de iterații j si k în limitele buclei asa încât se scrie un element cu indicele 
(a*j+b) într-un vector si apoi se citeste acelasi element din vector, de asta data cu 


indicele (c*k+d), unde a, b, c, d apartin lui Z. Altfel spus, o bucla este 


nevectorizabila daca c.m.m.d.c. (a, c) divide (b - d). Prin prisma acestui criteriu de 
ex., rezulta imediat ca bucla de mai jos este vectorizabila (2 nu divide 3) : 

for i = 1 to 100 

X(41+3) = X(21) + YU); 

Lungimea fizica a registrilor vectori este fixa si deci fatalmente limitata 
(<=M). De multe ori în soft se lucreaza cu vectori de lungime mai mare decât M 
(lungimea registrilor vectori) sau se lucreaza cu vectori de lungime necunoscuta în 
momentul compilarii, ca în exemplul buclei SAXPY (Single Precision A*X+Y) de 
mai jos: 

fori=1ton 

YQ) = a* XG) + YU); 

În astfel de cazuri, bucla se rescrie utilizând tehnica "strip mining", care 
reprezinta o tehnica ce permite generarea de cod program în urma compilarii astfel 
încât fiecare operatie vectoriala sa se efectueze cu vectori de lungime mai mica 
decât M. În urma aplicarii acestei tehnici, bucla SAXPY devine : 

start = 1 

lungvec = (n mod M) ; 

for j = 0 to (n / M) do; întreg trunchiat 

for i = start, start + lungvec -1 do 
Y) =a* Xi) + YW); 


enddo 


start = start + lungvec; 
lungvec = M; 
enddo 
De remarcat ca in prima iteratie (j = 0) se opereaza pe vectori de lungime (n 
mod M) iar în celelalte iteratii (j = 1, 2, ...) se opereaza asupra unor vectori de 
lungime maxima admisa M. Rezulta deci ca ar fi necesara o resursa speciala 
(registru) care sa controleze lungimea vectorilor asupra carora se opereaza la un 
moment dat. 
Sa consideram acum o secventa de program destinata înmultirii a doua 
matrici A = B x C, de ordinul (100x100), ca mai jos. 
for i = 1 to 100 do 
for j = 1 to 100 do 
A(,]) = 0 
for k = 1 to 100 do 
A(ij) = AGJ) + BGK) * C(ky) 
enddo 
enddo 
enddo 
Dupa cum se stie, exista doua moduri de memorare a unei matrici in memoria 
principala : modul "row major" si respectiv modul "column major" ca in figura 


3.28. 


Row major paz poo ez F--]ro0-fi007]---[100-100 
Column major PA Epoo e e Pro r00]-—-[100.100 


Figura 3.28. Moduri de memorare ale matricilor în memorie 


În cazul buclei de program anterioare, în ipoteza memorarii matricilor dupa 
legea "column major", rezulta pas//C//=1 si pas//B//=100. În ipoteza memorarii 
dupa cealalta lege, ar rezulta pas//C//=100 si pas//B//=1. Oricum, rezulta clar 
necesitatea unor instructiuni de încarcare / memorare care pe lînga adresa de baza 
si lungimea vectorului sa aiba ca parametru si pasul acestuia. Vectorii cu pasul 
diferit de 1 cauzeaza complicatii în accesul la memoria întretesuta. Pentru 
exemplificare sa consideram 16 module de memorie cu acces intretesut având 
timpul de acces ta. Timpul necesar pentru a incarca un vector cu 64 elemente având 
pasul 1 este (4Tciclu + 4ta) unde Tciclu = durata unui ciclu din structura pipeline a 
procesorului vectorial. La cealalta extrema, timpul necesar pentru a încarca un 
vector de aceeasi lungime având însa pasul 32 este (64Tciclu + 64ta), deci mult 
mai mare. Pentru eliminarea problemelor implicate de pasul vectorului (latenta 
mare a memoriei pentru pasul diferit de 1) se cunosc mai multe solutii bazate pe 
îmbunatatirea arhitecturilor de memorii întretesute. De exemplu, o matrice de 8 x 8 


poate fi memorata în 8 blocuri de memorie cu acces intretesut ca in figura 3.29. 


Figura 3.29. Memorarea unei matrici într-o memorie cu acces întretesut 


Se observa ca pasul unui vector "rand" este 1, iar pasul unui vector "coloana" 
este 9. Cum 2 elemente succesive ale unei coloane se afla memorate în module 
succesive de memorie, printr-o proiectare adecvata a adresarii modulelor bazat pe 
pasul vectorului accesat, se poate obtine în acest caz o accesare optimala a 
vectorilor "coloane" (la fel de rapida ca si accesarea unui vector "rând" care are 
pasul =1). În general daca pasul vectorului este relativ prim cu numarul de module 
de memorie, se pot elimina latentele ridicate prin organizari similare. Datorita 
frecventei accesarii în cazul unor algoritmi numerici diversi a vectorilor diagonali, 
se impune si optimizarea accesului la acesti vectori. Daca numarul modulelor de 
memorie este o putere a lui 2, nu poate fi optimizat simultan accesul la vectorii 
coloana si respectiv la cei diagonali . În acest caz se utilizeaza p module de 


memorie, unde p este un numar prim. O asemenea arhitectura de memorie este 


implementata in cazul supercomputerului BSP (Burroughs Scientific Processor - 
compania Unisys). In figura de mai jos (3.30) se prezinta o astfel de structura cu 5 
module, avand memorata o matrice de 4x4. Pasul vectorilor rand este 1, cel al 
vectorilor coloana este 6 iar cel al vectorilor diagonali este 7. De remarcat ca 
accesul optimizat simultan la cele trei tipuri de vectori este posibil datorita faptului 


ca numarul de module al memoriei (5) este relativ prim cu pasii vectorilor (1, 6, 7). 


Selectie 


Citire coloana 


Aliniere 


Figura 3.30. Optimizarea memorarii vectorilor linie, coloana si diagonali 
În acest caz, alinierea ar fi fost efectiva daca sar fi accesat de exemplu 
vectorul diagonal 00 11 22 33. Evident ca selectia elementelor, citirea si alinierea 
se fac comandate de un automat, în baza adresei de baza, lungimii si pasului 
vectorului accesat (citit în acest caz). 
Sa consideram acum o arhitectura vectoriala de tip SIMD (Single Instruction 
Multiple Data) ca in figura 3.31. Aceasta arhitectura SIMD se mai numeste si 


procesor matricial deoarece este constituita din mai multe procesoare identice, 


relativ simple, care executa acelasi program simultan, asupra unor date locale. 


Putem considera aceste structuri de calcul ca facând trecerea la arhitecturile de tip 


MIMD (Multiple Instruction Multiple Data). 


Front 
Computer 


Retea interconectare UE 


Figura 3.31. Arhitectura SIMD 

De precizat ca o astfel de structura de calcul executa un singur program 
asupra mai multor operanzi scalari simultan (ALU-uri multiple) sau acelasi 
program este executat în paralel de mai multe procesoare (UE) asupra propriilor 
seturi de date memorate în resursele locale. Nu intram aici în amanunte asupra 
topologiei si caracteristicilor diverselor tipuri de retele de interconectare, prin 
intermediul carora se realizeaza schimbul de date între unitatile locale de executie, 
acestea sunt arhicunoscute si prezentate în toate cartile generale de arhitectura 


sistemelor de calcul. Sa consideram o aplicatie care însumeaza 128.000 de 


elemente pe un sistem SIMD avand 128 unitati de executie distincte. Pentru 
început, un procesor specializat de I/O (front computer) plaseaza câte un subset de 
1000 de elemente in memoria locala a fiecarei unitati de executie (UE). Apoi 
fiecare UE proceseaza câte o secventa de program astfel : 
sum = 0; 
for (i = 0,1 < 1000;i=1+ 1) 
sum = sum + Al(i); 
Al(i) reprezinta o tabela locala continând 1000 de scalari, câte una în fiecare 
UE. Rezulta la final faptul ca fiecare dintre cele 128 de sume partiale va fi situata 


în alta UE. Programul SIMD pentru însumarea sumelor partiale distribuite ar fi: 


limit = 128; 
half = 128; 
repeat 
half = half/2 


if(Py >= half && Py < limit) send (Py-half;sum); 
if(Py < half) sum = sum + receive( ); 
limit = half; 
until (half = = 1); 
Functia send(x,y) are parametrii x = adresa procesor destinatie, y = variabila 


emisa. Precizam ca am notat prin P numarul unitatii de excutie, deci Py € {0, 1, 


2,....,127}. Send / Receive sunt functii emisie / receptie prin / din reteaua de 


interconectare a unitatilor de executie aferente SIMD. Suma finala se va obtine in 
UE o. Timpul de executie este de ordinul O(log2N), unde N=numarul de UE spre 
deosebire de un sstem conventional tip SISD care ar realiza adunarea sumelor 
partiale intr-un timp O(N). Secventa anterioara poate fi scrisa mai elegant, prin 
eliminarea variabilei half, ca mai jos 
limit = 128; 
repeat 
if(Py >= limit/2 & & Pp < limit) send (Py-limit/2;sum); 
if(Pp < limit/2) sum = sum + receive( ); 
limit = limit/2; 
until (limit = = 1); 
Buclele conditionate implica si ele anumite cerinte in procesarea vectoriala. 
De exemplu sa consideram secventa urmatoare : 
for i = 1 to 100 do 
if(X(i) diferit de 0) then 
X(i) = XG) + YU); 
endif 
enddo 
Pentru ca secventa sa fie vectorizabila rezulta necesitatea existentei unui 
registru vector de mascare, de lungime egala cu lungimea registrilor vectori. Acest 


A 


registru va contine elemente pe '0' sau '1', în conformitate cu testul facut asupra 


unui vector pe o anumita conditie. Operatiile vectoriale se vor executa numai 
asupra acelor elemente din vector carora le corespunde un element pe '1' în 
registrul de mascare. Considerând adresele de baza ale vectorilor X si Y memorate 


în registrii Rx respectiv Ry, bucla anterioara este echivalenta cu urmatoarea 


secventa de instructiuni masina vectoriala : 


LV VI, Rx; V1<-MEM/Rx 
LV V2, Ry; V2<-MEM/Ry 
LD FO,#0; instr. scalara FO<-0 


SNESV FO, V1;seteaza elementele reg. de mascare aferent 
elementelor V1(i) diferit de 0, i = 1-100 
ADDV VI, VI, V2; V1<- (V1)+(V2) 
SETVM; seteaza toate elementele reg. de mascare VM 
SV Rx, V1; VI -> MEM/Rx 
Exista bucle de program nevectorizabile datorate unor dependente de date 
"ascunse", generate de existenta unor variabile scalare, ca mai jos : 
x =0; 
for i = 1 to 100 do 
x=x+ AD * BG); 
enddo 
Aceasta bucla nevectorizabila se poate transforma în urmatoarea secventa 


semi-vectorizabila, obtinuta prin transformarea scalarului în vector si care 


paralelizeaza 100 de înmultiri care se executau serial în secventa anterioara : 
y =0; 
for i = 1 to 100 do 
X() = AG) * BG); vectorizabil 
enddo 
for i= 1 to 100 do 
y =y + X(i);_ nevectorizabil 
enddo 
Multe dintre supercomputerele actuale reprezinta multiprocesoare formate 
din mai multe procesoare vectoriale care proceseaza în paralel, având deci un 
accentuat paralelism spatial. În acest context sa consideram bucla de program : 
for i = 1 to n do 
XG) = Y@) + ZU); (1) 
Y (+3) = XU +4); (2) 
enddo 
Un compilator inteligent din cadrul unui sistem vectorial multiprocesor, 
trebuie sa sesizeze potentialul paralelism din cadrul acestei secvente precum si 
dependentele de date dintre relatiile (1) si (2). Secventa de mai jos va fi 
transformata astfel : 
for j=1 to n step 3 do 


for i=j to j+2 doall 


X= Y@)+Z(); (1) 
Y(it3)=X(i4+4)_ ; (2') 
enddoall 
enddo 

Se observa ca sau obtinut de fapt 2 bucle vectorizate, deci sau eliminat 
dependentele de date. Instructiunea "doall" determina executia paralela, pe 
procesoare distincte, a secventelor (1') si (2'), acum perfect vectorizabile si 
independente. 

Desigur ca generarea de cod vectorial sau cod vectoriakparalel prin 
intermediul unor compilatoare pe limbaje conventionale, nu poate exploata optimal 
procesarea vectoriala respectiv multiprocesarea vectoriala. Actualmente, se 
lucreaza intens, cu deosebire în Statele Unite ale Americii, pentru elaborarea de noi 
limbaje specifice programarii vectoriale / concurente (IBM Parallel Fortran, Cedar 
Fortran, limbajul VPC - un supraset vectorial / concurent al limbajului C, etc.). 
Cert este ca odata cu avansul tehnologiei VLSI, pretul acestor microprocesoare 
vectoriale va scadea si ele vor patrunde tot mai masiv pe piata. Înca din 1988 firma 
Ardent a realizat un CPU în jurul unui microprocesor RISC + un coprocesor 
vectorial integrat la pretul de numai 180$. Procesarea vectoriala are o veche istorie, 
având totodata realizari deosebit de performante. Ca si procesarea paralela la 
nivelul instructiunilor, ea a produs un impact puternic atât asupra proiectarii 


hardware cât si asupra compilatoarelor. Oricum, dezvoltarea compilatoarelor 


reprezinta provocarea esentiala si in aceste arhitecturi paralele. 

În concluzie, am prezentat pe scurt aceste câteva idei relative la procesarea 
vectoriala întrucât reprezinta un concept arhitectural de referinta în proiectarea unui 
procesor performant (MMX) chiar daca nu intra strict în categoria arhitecturilor cu 
paralelism la nivelul instructiunilor care se abordeaza cu precadere în aceasta 


lucrare. 


4. METODE ANALITICE DE EVALUARE SI OPTIMIZARE 


În cele ce urmeaza se va prezenta un set de analize, teoretice dar si pe baza de 
analiza numerica, asupra performantei arhitecturilor RISC superscalare cu busuri si 
memorii cache separate (I-Cache, D-Cache) si respectiv unificate. Aceasta 
problema este extrem de putin dezbatuta în literatura de specialitate, iar multe 
dintre aspecte nu sunt tratate deloc. Majoritatea specialistilor considera ca evidenta 
superioritatea globala a cache-urilor separate implementate în cadrul procesoarelor 
RISC superscalare si VLIW. În implementarile comerciale cunoastem doar câteva 
exceptii în acest sens: arhitectura RISC superscalara Power PC 601 si anumite 
microprocesoare Hewlett Packard Precision Architecture (HP- 7200), care 
implementaza busuri si memorii cache unificate pe instructiuni si date, exclusiv din 
motive de costuri. 

În mod traditional, cercetatorii abordeaza problemele de evaluare a 


performantelor arhitecturilor pipeline, superscalare s VLIW, prin intermediul unor 


ample programe de simulare. Pentru aceasta este necesara dezvoltarea in principal 
a urmatoarelor instrumente: un compilator C sau alt limbaj "tinta" - arhitectura 
cercetata, eventual un scheduler pentru optimizarea programului obiect generat prin 
compilare, un simulator parametrizabil al arhitecturii si în fine, o suita de 


benchmark-uri care dupa compilare si optimizare, vor fi procesate pe simulatorul 


parametrizabil. Este clar ca desi si-au dovedit în timp utilitatea si eficienta, aceste 
tehnici sunt deosebit de laborioase necesitând - dupa cum am mai aratat - lucrul în 
echipa al mai multor specialisti pe o perioada de câtiva ani. În plus, o rezerva la 
aceasta abordare este data de gradul de reprezentativitate al benchmark-urilor 
utilizate în simulare si care niciodata nu vor putea epuiza totalitatea aplicatiilor 
posibile în activitatea de zi cu zi a utilizatorului. De asemenea, aceste complexe 
instrumente de investigare se preteaza doar la o anumita arhitectura particulara. 

Ca o alternativa, se va încerca în acest capitol, dezvoltarea unor modele 
analitice originale în evaluarea performantei. Se vor dezvolta deci modele analitice 
bazate pe conceptele de vector de coliziune si automat finit, destinate în particular 
compararii performantelor cache-urilor separate si respectiv unificate. De asemenea 
vom dezvolta în acelasi scop si modele hibride, atât de natura analitica cât si 
numerica. Avantajul unei asemenea abordari consta în evitarea clasicelor metode 
bazate pe simulare, consumatoare de timp, resurse materiale si umane enorme. Pe 
baza unor metode analitice ca cele dezvoltate aici se pot lua decizii rapide cu 
privire la proiectarea optimala si performanta unor module functionale din cadrul 
arhitecturii. Un alt avantaj ar consta în faptul ca rezultatele obtinute prin aceste 
metode sunt practic independente de benchmark-urile utilizate în simulari, 
inevitabil si ele limitate si particulare. De asemenea, metodele acestea sunt practic 


independente de multe particularitati ale arhitecturii cercetate. 


Revenind la una din problemele deschise ce urmeaza sa fie abordate aici, se 
precizeaza câteva aspecte. Este cunoscut faptul ca memoriile cache cu busuri 
separate detin avantajul fata de cele unificate de a nu determina procese de 
coliziune. În cazul unificatelor acest lucru este inevitabil datorita conflictelor de 
acces la spatiile de instructiuni si date, având în vedere procesarea pipeline RISC a 
instructiunilor [Smi95, Hen96, Sto93, VinL96]. Din acest punct de vedere 
performanta unificatelor pare a fi net mai scazuta. Un alt dezavantaj ar consta în 
interferentele instructiuni - date pe care unificatele le implica, aspect iarasi extrem 
de putin studiat în literatura. 

În acest sens, se considera spre exemplificare un procesor scalar pipeline de 
tip RISC idealizat, având rata de hit in cache-uri de 100%, latenta tuturor 
instructiunilor de un tact, predictie perfecta a branch-urilor, fara dependente intre 


instructiuni, etc. 


Cache 


I-CACHE D-CACHE unificat 
M ko N ko M+N ko 


Figura 4.1. Cache-uri Harvard (separate) respectiv Princeton (unificate) 


Un astfel de procesor, avand busuri si cache-uri separate ar obtine o rata de 
procesare IR (Issue Rate) ideala de o instructiune per tact. Un procesor similar, 
avand insa cache-uri unificate ar obtine o rata ideala: 

IR = 1/ (1+Pmem) [instr./tact], (4.1), 

unde: Pmem reprezinta procentajul instructiunilor LOAD / STORE active 
dintr-un program dat. Cum Pmem = 0.4 tipic pe programele de uz general, rezulta 
ca rata medie de procesare IR scade dramatic de la o instructiune / tact la 0.71 
instructiuni / tact, arhitecturile unificate determinând deci o scadere a performantei 
cu 30% în acest caz. Acest tip de argument, simplist, este unul forte în justificarea 
superioritatii separatelor [Hen96, Sta96, Bha96]. 

Totusi, în opinia autorului, exista cîteva argumente care pot face din 
arhitecturile unificate arhitecturi deosebit de atractive. În primul rând aceste busuri 
si cache-uri unificate simplifica hardware-ul procesorului, întrucât necesita numai 
un set de logica de control, numai un registru de adrese si decodificator de adrese si 
numai o magistrala de legatura între CPU si memorie (v. Fig.4.1). Din punct de 
vedere al complexitatii proiectarii si implementarii reale, cache- urile unificate sunt 
mai facil de integrat decât cele separate [Rya93, IBM93]. În al doilea rând, 
latentele anumitor instructiuni (de exemplu LOAD) pot masca efectele 
defavorabile ale coliziunilor [VinL96]. În fine, un al treilea avantaj consta în faptul 


ca separatele detin o rata de miss cu 5-14% mai mare decât cele unificate, acestea 


din urma oferind deci o mai buna utilizare, raportat la capacitati egale. Acest ultim 
aspect însa, este extrem de putin investigat totusi, la ora actuala. 

Se prezinta în continuare, în tabelul 4.1, preluat din [Hen96], ratele medii de 
miss rezultate în urma unor simulari laborioase realizate pe statii DEC 5000 (Alpha 
21064) ale benchmark-urilor SPECint '92. S-au considerat cache-uri mapate direct, 
cele mai facil de integrat în microprocesor, având 32 octeti / bloc. Procentajul 
referintelor la I-Cache a fost de 75%, considerat a fi tipic. O posibila explicatie, în 
opinia autorului, a ratei de hit superioare în spatiul de instructiuni, are la baza 2 
motive: frecventa net superioara a acceselor la Cache si respectiv o mai buna 
compactizare a spatiului de instructiuni în raport cu cel de date în cadrul 
benchmark-urilor SPECint 92. Aceste motive ar explica în buna masura si rata de 
hit superioara corespunzatoare cache-urilor unificate. În plus, cache- urile unificate, 
spre deosebire de cele separate, permit o balansare dinamica între spatiile de acces 
la instructiuni si respectiv date [Rya93]. De altfel si aceasta problema a balansarii 
optimale între ECache si D-Cache este o problema deschisa în opinia autorului. 
Drept dovada, se prezinta capacitatile -Cache si D-Cache alocate în cadrul unor 
microprocesoare MEM actuale de tip comercial. 

- AMD KS: 16ko 4 - "way set associative" I-Cache, 8ko D-Cache. 

- Pentium Pro si Alpha 21164: 8ko I-Cache, 8ko D-Cache. 


- MIPS R 10000: 32ko I-Cache, 32ko D-Cache. 


- Ultra SPARC: 16ko I-Cache, 16ko D-Cache; Super SPARC: 20ko I- 
Cache,16ko D-Cache. 

- IBM RS/6000: 8ko I-Cache, 64ko D-Cache 

Contradictia rezida in faptul ca toate acestea sunt microprocesoare de uz 
general si deci trebuie sa execute practic aceleasi programe! Probabil din aceste 
motive, multe (dar nu toate!) procesoare RISC superscalare comerciale au cache-ul 


de instructiuni de capacitate mai mare decât cel de date. 


Tabelul 4.1. Rata de miss pt. arhitecturi cache separate vs. unificate 


D-Cache % CACHE Unificat % 


24.61 13.34 


20.57 


15.94 


De exemplu, masurat pe benchmark- urile SPECint 92, microprocesorul 
superscalar Super SPARC (SUN) atinge o rata de hit în Cache de 98% iar în D- 
Cache de 90% [Sun92]. Singura exceptie - alaturi de câteva microprocesoare HP 


7200 - dupa cum am mai aratat, o constituie microprocesorul superscalar Power PC 


601 [Smi94, IBM93, Weis94] care combina un bus si un cache unificat de mare 
capacitate (32 ko), având o rata de fetch maxima de 8 instructiuni, un buffer de 
prefetch de 8 instructiuni si posibilitatea de a lansa in executie maxim 3 instructiuni 
din acest buffer de prefetch. Din pacate nicaieri nu se justifica alegerea acestei 
solutii (departe de a fi optima dupa cum se va putea constata) cu parametrii 
aferenti, pe o baza teoretica sau/si de simulare, ci doar pe faptul ca "e mai simplu 
asa" si pe considerente cel mult de " bun simt". 

În continuare se vor prezenta câteva metode originale de investigare a 
performantei cache-urilor si busurilor unificate pe instructiuni si date (I/D) 
comparativ cu cele separate, implementate în cadrul arhitecturilor cu executii 
multiple ale instructiunilor. De asemenea se vor dezvolta câteva consideratii legate 
de determinarea unor conditii analitice, referitoare la o proiectare optimala a 
acestor arhitecturi. Se precizeaza ca - cu exceptia ultimelor doua metode prezentate 
în paragrafele 4.3 si 4.5 - toate celelalte metode dezvoltate aici sunt de tip cvasi- 
analitic (analiza teoretica si numerica) si abordeaza aceasta problematica exclusiv 
prin prisma proceselor de coliziune implicate de catre arhitecturile cu busuri 
unificate (fara a aborda deci efectiv problema eficientei cache-urilor ci doar aceea a 
busurilor. În capitolul 5 însa, se va aborda problema în toata complexitatea ei, pe 
baza de simulare). Penultima abordare însa, din paragraful 4.3, încearca tot pe o 
baza teoretica, de data aceasta mai simpla, o tratare globala a comparatiei analitice 


între cache-urile unificate si cele separate tinând cont de toate fenomenele care apar 


aici (coliziuni si respectiv procese de hit/miss in cache-uri). In ultimul paragraf, se 
prezinta câteva consideratii de natura analitica relative la stabilirea unor parametri 
optimali pentru o arhitectura superscalara, pe baza principiului "procese multe, 


resurse hardware putine", deci tinând cont de hazardurile structurale implicate. 


4.1. EVALUARI PE BAZA CONCEPTULUI VECTORILOR DE 
COLIZIUNE 


4.1.1. PERFORMANTA UNUI PROCESOR SUPERSCALAR CU BUSURI 
UNIFICATE 


Scopul principal consta în determinarea cantitativa a scaderii de performanta 
pentru o arhitectura superscalara având  busuri unificate (si implicit cache-uri 
unificate) fata de una cu busuri separate (si implicit cache-uri separate, v. Fig.4.1). 
Se vor avea în vedere deci, exclusiv procesele de coliziune implicate de catre 
primul tip de arhitectura. 

Se considera o arhitectura simplificata de procesor superscalar avînd rata de 
fetch a instructiunilor (FR) de 2 instructiuni, rata maxima de executie (IRmax) tot 
de 2 instructiuni si rata de hit în cache de 100%. Se considera de asemenea ca 
procesorul detine un cache unificat având doua porturi de citire -scriere (realist) si 
ca include un mecanism perfect de predictie a branch-urilor. Fiecare instructiune 


este procesata într-o structura pipeline având 4 stagii cu urmatoarea semnificatie: 


IF - fetch instructiune din I-Cache; 

ID - decodificare instructiune, selectie operanzi, calcul adrese in cazul 
instructiunilor LOAD / STORE si de salt; 

ALU/MEM - faza de executie, respectiv acces la memoria de date; 

WB - înscriere a rezultatului în registrul destinatie. 

Desigur ca în cazul procesarii pipeline, fazele IF si MEM nu se pot suprapune 
datorita busurilor de legatura unificate între CPU si cache. Din punct de vedere al 
proceselor de coliziune (IF, MEM), exista 2 tipuri de instructiuni distincte: 
instructiunile LOAD / STORE, singurele care exploateaza nivelul MEM (grupul A) 
si respectiv restul instructiunilor masinii care deci nu exploateaza nivelul MEM 
(grupul B). Bazat pe conceptul de vector de coliziune atasat unei structuri pipeline 
[Sto93, VinL96], prezentat de altfel si în capitolul 2 al acestei lucrari, se poate 
scrie; 

VC(A,A) = VC(AB) = 010 (4.2) 

VC(B,A) = VC(B,B) = 000 (4.3) 

Prin VCG,j) am notat vectorul de coliziune al unei instructiuni curente din 
grupul i urmata de o instructiune din grupul j, unde ij apartine {A,B}. Avand in 
vedere amintitele caracteristici ale arhitecturii simplificate considerate, am 
dezvoltat doua automate de aducere (fetch) a instructiunilor pentru aceasta 
arhitectura. In cele 2 figuri urmatoare (4.2, 4.3), se prezinta principiul utilizat in 


constructia acestor automate, prin reprezentarea unor tranzitii tipice. Automatele 


reprezentate complet pot fi gasite in lucrarea [VinL96]. In fiecare reprezentare, in 
dreptunghi este înscrisa instructiunea dubla adusa din Cache (AA, AB, BA, BB) 
si cei doi vectori de coliziune aferenti. Din fiecare stare ies 4 arce, in conformitate 
cu cele 4 posibilitati de aducere a urmatoarei instructiuni duble. Pe fiecare arc este 
înscris un numar reprezentând numarul de tacte necesare pâna la startarea aducerii 
urmatoarei instructiuni. Acest numar este functie de vectorii de coliziune care 


definesc starea respectiva a automatului. 


A(110) A(010) 


3 5 3 3 
A(010) A(010) A(010) B(000) B(000) A(010) B(000) B(000) 


Figura 4.2. Principiul tranzitiei în primul automat de fetch 


A(110) A(010) 


Figura 4.3. Principiul tranzitiei celui de al 2-lea automat de fetch (mai agresiv) 


Am dezvoltat doua modele de astfel de automate, al doilea fiind mai agresiv 
în strategia de aducere a instructiunilor dupa cum se poate observa (v. Figura 4.3). 
În continuare scopul a fost sa se determine o relatie de tipul: 

FR = IR = f(Pmem), exprimat în [instr./tact] (4.4), 
unde FR si IR reprezinta ratele medii de fetch respectiv executie a instructiunilor 
iar Pmem reprezinta procentajul instructiunilor LOAD / STORE active din 
program. În acest scop, sa scris un program simulator pe baza algoritmilor de 
fetch implementati în cadrul celor doua automate. Acest program cere utilizatorului 
parametrul Pmem. Odata furnizat acest parametru programul genereaza automat 10 
"programe" (fisiere text), fiecare dintre acestea continand câte 100.000 de 
"instructiuni" A si B dintre care Pmem*100% sunt instructiuni din grupul A, 
distribuite practic aleator în cadrul fisierului. În continuare pe baza acestor fisiere 
generate, se simuleaza procesarea pe baza celor doua modele de automate anterior 
prezentate. În fiecare caz se calculeaza rata medie de procesare IR [instr./tact]. 
Interesant este faptul ca toate cele 10 rate IR obtinute pentru un anumit procentaj 
Pmem, sunt cvasiidentice, fiind practic independente de distributia instructiunilor 
din grupul A. Asadar IR depinde doar de procentajul instructiunilor A în program. 
Se prezinta functiile IR = f(Pmem) asa cum au fost obtinute pentru cele doua 


modele analizate(Figura 4.4). 


Pentru Pmem = 30% (tipic), rata de procesare a modelului mai agresiv este 
IR = 1.49 instr./tact fata de IR = 2 instr./tact cât ar procesa în aceleasi conditii un 
procesor avînd cache-uri separate pe instructiuni si date. Asadar rezulta o degradare 


cu cca. 26% a performantelor, datorita proceselor de coliziune implicate. 


Figura 4.4. Variatia ratei de procesare pt. cele 2 automate elaborate 
În tabelul 4.2 se prezinta ratele de procesare obtinute în baza modelului mai 
agresiv de automat, în urma "executiei" unor secvente de program de tip "trace", de 
aceasta data deterministe deci, de cca. 10.000 instructiuni, apartinând celor 8 
benchmark-uri consacrate, dezvoltate la Universitatea din Stanford. Se prezinta mai 


Jos caracteristicile trace-urilor analizate si ratele de procesare obtinute. 


Tabelul 4.2. Performante obtinute pe benchmar-urile Stanford 


Distrib. LOAD / STORE % 


24 1.56 


De remarcat si in aceste evaluari facute pe secvente reale ale unor programe 


consacrate de test, o deplina concordanta cu rezultatele evaluarilor anterioare, 
bazate pe distributii cvasialeatoare. S-a obtinut o performanta medie de 1.52 
instr./tact (la o medie de 26% a distributiei instructiunilor LOAD / STORE în 
cadrul secventelor de program considerate), adica o degradare cu cca. 24% a 
performantei raportat la un procesor echivalent dar cu busuri si cache-uri separate. 
Detalii suplimentare despre aceasta problema pot fi gasite în [VinL96]. 

Totusi, modelele si metoda utilizata sunt relativ simpliste, rezultatele obtinute 
fiind considerate doar orientative. Mai mult, aceste rezultate sunt defavorabile 
arhitecturilor cu busuri unificate întrucît metoda utilizata nu are în vedere 
fenomenul de prefetch. Acesta poate "ascunde" mult din asteptarile provocate de 
catre procesele de coliziune. Un alt punct slab al prezentei abordari consta în faptul 
ca nu am considerat dependentele posibile si probabile între instructiunile care 


urmau a fi lansate în executie si care limiteaza serios rata de procesare. Aceasta 


simplificare este însa comuna ambelor modele de arhitecturi comparate. Oricum, în 
continuare se va aborda aceeasi problema însa pe baza unui model mai realist, 
parametrizabil si care sa tina cont de observatiile anterior formulate. Dupa cum se 
va putea constata, diferenta reala de performanta între arhitecturile cu cache-uri 
separate si respectiv cele unificate, devine mult mai mica, facând în opinia 
autorului din arhitecturile unificate o optiune posibil superioara în anumite conditii, 


prin prisma raportului performanta / cost implicat. 


4.1.2. INFLUENTA INSTRUCTIUNILOR LOAD ASUPRA 
PERFORMANTEI ARHITECTURILOR UNIFICATE 


În continuare, bazat pe acelasi concept al vectorilor de coliziune [Sto93], se 
va încerca determinarea într-un mod cantitativ, a influentei defavorabile a 
instructiunilor de tip LOAD asupra performantei unui procesor RISC scalar 
idealizat, având busuri unificate pe instructiuni si date. Pentru aceasta, se va 
considera o arhitectura scalara RISC având 5 stagii de procesare pipeline -izate (IF, 
ID, ALU, MEM, WB). De asemenea, se considera un LDS (Load Delay Sloat) de o 
instructiune (tipic), precum si o unitate functionala de LOAD nepipeline-izata. Un 
astfel de procesor RISC, având busuri si cache-uri separate în spatiile de 
instructiuni si date (arhitectura Harvard) si care are latente ale instructiunilor si 
memoriilor de un tact, ar realiza o rata de procesare: 


IRs = 1/(1 + Pl) (4.5) 


Prin Pl am notat procentajul instructiunilor LOAD active dintr-un program 
dat. Am considerat ca procesorul temporizeaza un tact, prin hardware sau software 
scheduling, in cazul fiecarei instructiuni LOAD executata. In continuare se propune 
determinarea unei relatii de tipul [Ru = f(Pl, Ps), pentru o arhitectura non-Harvard, 
unde Ps reprezinta procentajul instructiunilor STORE active dintr-un program dat. 
Evident ca: PI + Ps = Pmem. Modelul de procesare pentru o astfel de arhitectura cu 
busuri unificate, este prezentat în continuare în figura 4.5. Prin L, S si X am notat o 
instructiune LOAD, STORE sau alt tip de instructiune adusa la finele fazei IF. 
L(0010) si S(0010) semnifica faptul ca o instructiune initiala în program de tip 
LOAD sau STORE, poate determina peste bua impulsuri de tact o coliziune la 
busurile unificate si la cache-ul comun, prin suprapunerea fazelor MEM aferente 
acestor instructiuni cu faza IF aferenta uneia dintre instructiunile urmatoare. 
Desigur ca în filosofia RISC doar instructiunile LOAD / STORE pot determina 


asemenea procese de coliziune. 


aera aes | X(1000) | 


Eo 


L(0010) 
(0010) 


4 
(0009) 140010) storo) X(0000)  L(0010) S(0010) 


Figura 4.5. Un model simplu de procesare pt. un procesor scalar RISC tip Princeton 


Numarul înscris pe cele 3 arce care ies din fiecare stare semnifica numarul de 
tacte dupa care se poate aduce o noua instructiune (L, S sau X), relativ la 
instructiunea curenta. Acesta este principiul de constructie al grafului anterior, care 
modeleaza procesarea instructiunilor pe un procesor scalar RISC de tip non- 
Harvard. Dupa cum se observa, graful are 12 stari Si, i = 1,...,12. Probabilitatile Pi 
ca automatul sa se afle într-o anumita stare Si se pot determina pe baza celor 12 


ecuatii liniare omogene de echilibru precum si a relatiei de normalizare: 


Pi=1 (4.6) 


Automatul poate starta din una dintre cele 3 stari marcate cu (*). Din punct de 


vedere teoretic avem: 


12 
IRu = 1/9 Pi* Ni, (4.7), 


i=l 
unde: Ni = latenta aferenta starii Si 
Pe baza acestui model s-au realizat simulari pe o vasta arie de programe în 
scopul determinarii ratei de procesare IRu = f(Pl, Ps). În graficul urmator (figura 
4.6) se prezinta rezultatele obtinute pentru procentaje Pl = Ps cuprinse între 0% si 


45% relativ la o arhitectura non-Harvard de procesor. 


—@— UNIFICATE 
—N— SEPARATE 


Figura 4.6. Comparatie a performantelor unui model RISC Harvard respectiv Princeton 


De asemenea se prezinta IR = f(Pmem) pentru o arhitectura Harvard, în 
scopul determinarii diferentelor de performanta între cele doua optiuni 


arhitecturale. 


Se poate concluziona ca pentru procentaje tipice de Pmem = 30% (dintre care 
50% LOAD-uri), performanta unui procesor RISC non-Harvard fata de unul 
Harvard scade cu pana la 18%, exclusiv din cauza proceselor de coliziune, dar 
acest fapt ar putea fi compensat dintr-un punct de vedere global de avantajele 
introduse în hardware printr-o astfel de arhitectura precum si de faptul ca 
arhitecturile unificate de cache-uri ofera o rata de hit superioara fata de cele 
separate cu cca. 10-15% dupa cum am mai mentionat [Hen96]. Pe de alta parte, 
instructiunile LOAD pot masca în parte procesele de coliziune la busurile comune 
(v. Fig.4.5). Aceasta analiza a abordat problema exclusiv din punct de vedere al 
proceselor de coliziune introduse de catre arhitecturile unificate. Detalii 
metodologice si rezultate suplimentare despre aceasta investigatie pot fi gasite în 


[VinL96]. 


4.2. NOI ABORDARI ANALITICE ALE ARHITECTURILOR MEM CU 
BUSURI UNIFICATE PE INSTRUCTIUNI SI DATE UTILIZAND 
AUTOMATE FINITE DE STARE 


4.2.1. PRINCIPIUL PRIMEI METODE DE ANALIZA 


Se propune dezvoltarea unui model teoretic de evaluare a performantei 
arhitecturilor pipeline cu executii multiple, bazat pe modelarea acestor arhitecturi 


folosind automate finite de stare. În particular se va aplica acest model în mod 


concret, in scopul evaluarii comparative a procesoarelor RISC superscalare având 
busuri si cache-uri unificate respectiv separate I/D, continuând astfel investigarea 
începuta anterior, de aceasta data pe o baza mai complexa si mai realista. De 
precizat ca evaluarea comparativa se va baza preponderent pe estimarea cantitativa 
a pierderii de performanta implicata de busurile unificate si datorata coliziunilor 
între fazele IF si MEM. 

Fata de modelul precedent, noutatea consta în aparitia unui buffer de prefetch 
de capacitate parametrizabila între nivelele IF si ID din cadrul structurii pipeline, 
care decupleaza practic procesul de prefetch de cel de executie propriu zisa (v. 
Fig.4.7). Am investigat 2 tipuri de structuri pipeline tipice pentru arhitecturile 
actuale: una având 4 stagii pipeline (IF, ID, ALU/MEM, WB) si alta având 5 stagii, 
cu stagii separate ALU si MEM (IF, ID, ALU, MEM, WB). Ca si în cazul 
precedent am considerat latenta tuturor instructiunilor de un tact si o predictie 
perfecta a branch-urilor. Unul dintre obiectivele importante ale acestei investigatii a 
fost acela de a determina fractiunea din timpul total al procesorului cât bufferul de 


prefech poate furniza instructiuni spre executie pe timpul coliziunilor. 


WB 


prefetch 


Figura 4.7. Un model de arhitectura pipeline decuplata 


În cazul structurilor pipeline cu 4 stagii, fiecare stare a automatului contine 2 
componente ortogonale notate S(IB) si S(ID). Componenta S(IB) reprezinta 
numarul de instructiuni memorate curent în bufferul de prefetch iar componenta 
SCD) reprezinta o valoare binara care daca este '1' arata ca în faza ID se afla o 
instructiune LOAD / STORE. Asadar componenta S(ID) arata daca este '1' ca în 
urmatorul impuls de tact se va face un acces la spatiul de date si prin umare 
procesul de prefetch va trebui stagnat. Analog, în cazul structurilor pipeline cu 5 
stagii, fiecare stare a automatului va contine 3 componente ortogonale: S(IB), 
SCD) si S(ALU). Primele doua au o semnificatie identica cu cea descrisa anterior. 
Componenta S(ALU) indica daca este '1' ca în faza ALU a structurii pipeline se 
afla o instructiune LOAD / STORE si deci peste un tact va apare un potential 
conflict la memorie care se va rezolva prin stagnarea prefetch-ului in tactul 
urmator. În acest caz, S(ID) va semnifica daca e '1' ca peste 2 tacte vom avea un 
conflict structural la memorie. 

Automatele dezvoltate vor avea 3 parametri importanti: rata de fetch a 
instructiunilor (FR-Fetch Rate), rata maxima de executie a instructiunilor (IR-Issue 
Rate) si respectiv capacitatea bufferului de prefetch exprimata în instructiuni (IBS- 
Instruction Buffer Size). Ca un exemplu, se prezinta automatul aferent unui 
procesor cu 4 stagii având FR = 2, IR = 2 si IBS = 4. Automatul contine 10 stari în 
acest caz. Probabilitatile de tranzitie din fiecare stare pot fi calculate functie de 


doar 2 parametri: P(2instr), adica probabilitatea ca sa se trimita în executie din 


bufferul de prefetch 2 instructiuni si care implicit sunt independente, si respectiv 
Pmem, care reprezinta probabilitatea ca instructiunea trimisa spre executie sa fie 
una de tip LOAD / STORE. Se considera ca daca bufferul de prefetch nu este gol, 
întotdeauna exista cel putin o instructiune care sa poata fi executata. Asadar, daca 
notam P(linstr) probabilitatea ca sa fie trimisa spre executie o singura instructiune, 
avem relatia de normare: 

P(linstr) + P(2instr) = 1 (4.8) 

Cu aceste precizari prezentam in cazul particular anterior descris, automatul 


aferent acestei arhitecturi. 


Stare prez. Tranzitie Stare urm. Probab. tranz. 

1. 0,0 Fetch 2, Ex 0 2,0 1 

2. 0,1 Fetch 0, Ex 0 0, 0 1 

3. 1,0 Fetch 2, Ex] 2,0 1-Pmem 
2,1 Pmem 

4. 1,1 Fetch 0, Ex 1 0, 0 1 - Pmem 
0,1 Pmem 

5. 2,0 Fetch 2, Ex 1 3,0 P(1) (1-Pmem) 
3,1 P(1) Pmem 

Fetch 2, Ex 2 2,0 P(2) (1-Pmem)2 


2,1 P(2)(1-(1-Pmem)2) 


6. 2,1 Fetch 0, Ex 1 1,0 P(1) (1-Pmem) 


8. 3,1 


9. 4,0 


10. 4,1 


Fetch 0, Ex 2 


Fetch 2, Ex 1 


Fetch 2, Ex 2 


Fetch 0, Ex 1 


Fetch 0, Ex 2 


Fetch 0, Ex 1 


Fetch 2, Ex 2 


Fetch 0, Ex 1 


Fetch 0, Ex 2 


1,1 
0,0 
0,1 
4,0 
4,1 
3,0 
3,1 
2,0 
2,1 
1,0 
1,1 
3,0 
3,1 
4,0 
4,1 
3,0 
3,1 
2,0 


2,1 


P(1) Pmem 
P(2) (1-Pmem)2 
P(2) (1-(1-Pmem)2) 
P(1) (1-Pmem) 
P(1) Pmem 
P(2)(1-Pmem)2 
P(2) (1-(1-Pmem)?) 
P(1) (1-Pmem) 
P(1) Pmem 
P(2) (1-Pmem)2 
P(2) (1-(1-Pmem)?) 
P(1) (1-Pmem) 
P(1) Pmem 
P(2) (1-Pmem)2 
P(2) (1-(1-Pmem)?) 
P(1) (1-Pmem) 
P(1) Pmem 
P(2) (1-Pmem)2 


P(2)(1-(1-Pmem)2) 


Pe baza acestui automat se poate scrie urmatorul sistem de 10 ecuatii liniare 
si omogene. Am notat: Pi - probabilitatea ca automatul sa fie in starea i, a = 


P(linstr), b= Pmem. 
Pl =(1 -a)(1-b)2 P6+P2+(1 - a) P4 
P2=b P4+(1 -a)(1-(1-b)2) P6 
P3 =a(1 -b) P6+(1 -a) (1 -b)2P8 
P4=abP6+ (l-a) (1-(1-b)2)P8 
P5 = P1 + (1 - b) P3 + (1 - a) (1 - b)2 (P5 + P10) + a (1 - b) P8 
P6 = b P3 +abP8+ (1 -a) (1 -( 1 -b)2) (P5 + P10) (4.9) 
P7 =a (1 -b) P5+(1-a) (1-b)2P7 +a(l - b) (P9 + P10) 
P8 =abP5+ab(P9+P10)+ (1-a)(1-(1-b)2) P7 
P9 =a(1 -b)P7+ (1-a)(1-b)2 P9 
P10 =abP7+ (1-a)(1-(1-b)2) P9 
Desigur ca exista relatia de normalizare: 


Pi=1 (4.10) 


Pe aceasta baza se pot determina dupa solutionarea sistemului 2 parametri 
deosebit de importanti: rata medie de executie a instructiunilor (IRu) si respectiv 


procentajul de timp cât bufferul de prefetch este gol (IBE) si deci nu mai poate 


"masca" eventualele procese de coliziune. În acest caz particular, acesti 2 parametri 
sunt: 

IRu = P3 + P4 +(2 - P(linstr)) (P5 + P6 +P7 +P8 + P9 + P10) (4.11) 

IBE = (P1 + P2) 100% (4.12) 

De observat ca rata medie de procesare pentru o arhitectura identica dar cu 
memorii si busuri separate (I-Cache, D-Cache) este: 

IRs = 2 - P(linstr) (4.13) 

Într-un mod analog pentru o structura pipeline cu 5 stagii si aceleasi 
caracteristici (FR = 2, IR = 2, IBS = 4) s-ar obtine un automat similar. Se prezinta 


în acest caz doar un exemplu de tranzitie dintr-o stare în alta în cazul acestui 


automat. 
Stare prez. Tranzitie Stare urm. Probab. tranz. 
3,1,0 Fetch2, Ex1 4,0,1 P(1) (1-Pmem) 
4,1,1 P(1) Pmem 
Fetch2, Ex2 3,0,1 P(2) (1-Pmem)2 


3,1,1 P(2)(1-(1-Pmem)2) 

În acest caz particular vom obtine însa un sistem de 20 ecuatii liniare si 
omogene. În general, pe baza automatului de tranzitii se obtine un sistem de N 
ecuatii liniare si omogene furnizat de ecuatia matriciala de echilibru: 

IPI=IPI*ITI (4.14), 


unde: 


IPI=IPI1P2...... PNI iar I T I = II ty I unde i, j apartin {1, 2, ..., N} 

S-au utilizat urmatoarele notatii : 

Pi = probabilitatea ca automatul sa se afle în starea i; 

N = numarul total de stari; N = (IBS + 1) * 4; 

tj = probabilitatea de tranzitie din starea i în starea j a automatului. 

Cum automatul trebuie sa fie la un moment dat în una dintre cele N stari, este 


îndeplinita relatia de normalizare: 


N 
J Pisi (4.15) 


Sistemul de N ecuatii omogene se poate rezolva prin metode numerice bine 
cunoscute. Dupa rezolvarea acestuia, probabilitatile obtinute vor fi folosite pentru 
calculul ratei medii de procesare (IRu) si respectiv a fractiunii de timp cât bufferul 
de prefetch este gol si deci nu poate "ascunde" procesele de coliziune aparute. 


Asadar, la modul general, se vor calcula urmatorii parametri importanti: 


IRu = f(P(2instr), Pmem, P1, ..., PN); (4.16) 
IRs = 2 - P(linstr); (4.17) 
IBE = f(P1,... PN) 100%. (4.18) 


În final, pe baza acestor relatii se vor putea compara ratele medii de procesare 
obtinute pentru diverse arhitecturi, stabilindu-se astfel o comparatie cantitativa, pe 


baza teoretica, a celor 2 tipuri de arhitecturi: cu busuri de memorie unificate 


respectiv separate I/D. S-au folosit modele care au necesitat rezolvarea unor 


sisteme de ecuatii liniare omogene de pana la 70 de ecuatii. 


4.2.1.1. REZULTATE OBTINUTE PE BAZA PRIMEI METODE 


În primul rând s-a dorit sa se compare performantele relative pentru 2 
arhitecturi cu busuri unificate: una cu 4 stagii, iar cealalta cu 5 stagii. Pentru 
ambele arhitecturi am considerat FR = IR = 2, IBS = 4 si Pmem = 0.2. Dupa cum 
se observa în figura 4.8 performantele sunt cvasiidentice în ambele cazuri. 
Teoretic, performantele arhitecturii cu 4 stagii sunt sensibil mai bune, însa 
consideram ca aceasta superioritate este practic neglijabila. Putem deci concluziona 
ca performanta celor 2 modele este practic aceeasi asa ca în continuare vom 
prezenta doar rezultatele obtinute pentru modelul cu 5 stagii de procesare. Mai 
mult, în baza altor investigatii realiste pe care le-am facut, a rezultat ca performanta 
scade nesemnificativ cu cresterea numarului de stagii din structura pipeline, din 


punctul de vedere abordat aici. 
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Figura 4.8. Variatia ratei de procesare (IR) pt. o structura pipeline Princeton cu 4 respectiv 5 stagii 


În cele ce urmeaza se vor prezenta curbele [Ru = f(P(2instr)) pentru diferite 
proportii ale instructiunilor LOAD / STORE în program (Pmem variabil). În figura 
4.9 se prezinta rezultatele obtinute considerând FR = IR = 2 si IBS = 4. În mod 
natural cresterea valorii parametrului Pmem determina degradarea performantei. În 
particular, pentru Pmem = 0, performanta unificatelor este identica cu cea a 
separatelor, întrucât nu exista probleme de coliziune care sa degradeze performanta 
primelor. Pentru valori tipice, de exemplu Pmem = 04 si P(2instr) = 05, 
performanta arhitecturilor separate este de 1.5 instr./tact iar în cazul celor unificate 
ea scade la 1.14 instr./tact, adica cu 24%. Dupa cum se va arata în continuare, 
aceasta diferenta de performanta poate fi redusa fie prin marirea parametrului IBS, 
fie prin marirea FR, fie prin marirea simultana a ambilor parametri. În figurile 4.10, 


4.11 se prezinta influenta capacitatii bufferului de prefetch asupra performantei 


arhitecturilor unificate. Sau ales in ambele cazuri IR = 2 si FR = 4, iar proportiile 
instructiunilor LOAD / STORE în cadrul programelor de 30% respectiv 40%, 
valori tipice de altfel. 

Important este in acest caz ca pentru aceiasi parametri tipici alesi în cazul 
anterior, anume Pmem = 0.4 si P(2instr) = 0.5, performanta arhitecturilor unificate 
atinge 1.48 instr./tact cu numai 1.2% inferioara arhitecturilor separate echivalente. 


De asemenea, performanta medie creste cu 10% de la un IBS = 4 la un IBS = 16. 
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Figura 4.9. Variatiile IR pt. o arhitectura Harvard resp. arhitecturi Princeton parametrizabile dupa 
Pmem 
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Figura 4.11. IR pt. diferite valori ale capacitatii bzfferului de prefetch (Pmem=30%) 
În continuare (fig.4.12) se prezinta influenta ratei de fetch a instructiunilor 
(FR) asupra performantei arhitecturii, practic în aceleasi conditii ca si în cazul 


anterior analizat (IBS = 16, Pmem = 40% si IR = 2). În acest caz, diferenta de 


performanta intre arhitecturile unificate si cele separate in conditii identice (Pmem 
= 0.4, P(2instr) = 0.5) este de doar 0.38%, adica realmente una nesemnificativa. 
Avand in vedere utilizarea mai buna a memoriilor cache unificate, este posibil ca 
pe ansamblu acestea sa se comporte chiar mai bine in conditiile de proiectare 
impuse prin parametrii alesi (FR = 8, IR = 2, IBS = 16), conditii considerate ca 


fiind deosebit de realiste. 
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Figura 4.12. IR pt. doua rate de fetch distincte (4,8) 

Pe aceasta baza, consider ca în ciuda parerii practic unanime, o proiectare 
având parametrii IR = N, FR = 2N,..., 4N, IBS = 2FR,.....,4FR si combinata cu un 
algoritm eficient de prefetch poate conduce arhitecturile unificate la performante 
comparabile celor separate. În plus, exista dupa cum deja am mentionat, 
simplificari atragatoare în proiectarea hardware a acestora. Figura urmatoare 


(fig.4.13) confirma faptul ca alegând capacitatea bufferului de prefetch de 16 


instructiuni si o rata de fetch de 4 sau 8 instructiuni, in ipoteza sustinuta de practica 
în care P(2instr) < 0.8, bufferul de prefetch ramâne gol mai putin de 4% din timpul 


total. 
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Figura 4.13. Procentajul de timp cât bufferul de prefetch este gol, pt. doua rate de fetch distincte (4,8) 

Acest lucru confirma faptul ca o strategie performanta de prefetch dublata de 
o acuratete ridicata în predictia branch-urilor, mascheaza practic total procesele de 
coliziune între accesele în spatiile de instructiuni respectiv date, facând astfel 
deosebit de atractiva arhitectura unificata. Am aratat deci ca principalul dezavantaj 
al arhitecturilor unificate - procesele de coliziune - poate fi eliminat total printr-o 
adecvata alegere a unor importanti parametri de proiectare. 

În urmatoarele 3 figuri (fig. 4.14, 4.15, 4.16), se prezinta evaluari cantitative 
ale ratei medii de procesare a instructiunilor (IR) functie de P(2instr) - gradul de 


A 


paralelism exploatabil - pentru diferite modele de procesoare. In fiecare caz, 


estimarile sunt facute pentru diferite distributii considerate rezonabile ale 
instructiunilor LOAD / STORE în program [Mil89]. De asemenea, în fiecare caz se 
prezinta si rata de procesare pentru cache-uri separate în scopul de a oferi o viziune 
sintetica si rapida asupra diferentei de performanta între cele doua arhitecturi 


analizate aici. 
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Figura 4.14. Comparatie separate vs. unificate pt. FR=4, IBS=8 si diferiti parametri Pmem 
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Figura 4.15. Comparatie separate vs. unificate pt. FR=4, IBS=16 si diferiti parametri Pmem 
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Figura 4.16. Comparatie separate vs. unificate pt. FR=8, IBS=16 si Pmem=40% 
Este clar ca o proiectare realista (de exemplu, FR = 8, IRmax = 2, IBS =16) 


poate practic anula diferenta de performanta între cele doua variante. 


În concluzie consider ca asemenea metode de evaluare a performantelor 
arhitecturilor cu paralelism în procesarea instructiunilor pot constitui o alternativa 
utila la abordarile conventionale bazate pe simulari ample. În particular, am aratat 
ca pierderea de performanta a arhitecturilor unificate comparativ cu cele separate, 
datorata coliziunilor, poate fi redusa semnificativ prin mecanisme adecvate de 
prefetch si o alegere corespunzatoare a parametrilor FR, IR si IBS. În plus, acestea 
prezinta avantajul fata de cache-urile separate de a avea o rata de hit superioara cu 
cca 10%. Astfel de metode teoretice de evaluare, au avantajul evitarii unor simulari 
care necesita timp si resurse enorme. Ele pot fi deosebit de utile în alegerea unor 
variante arhitecturale optimale în raport cu scopul propus. Totusi, un punct mai 
slab al prezentei abordari ar fi urmatorul: în practica, un branch predictionat de 
exemplu, în mod incorect ca nu se va face, determina golirea bufferului de 
prefetch. Prezenta abordare nu "prinde" acest aspect desi aceasta simplificare s-a 
facut pentru ambele modele arhitecturale comparate. În continuare se va dezvolta 


metodologia în vederea rezolvarii acestei probleme. 


4.2.2. O METODA IMBUNATATITA DE EVALUARE ANALITICA A 
ARHITECTURILOR MEM CU BUSURI UNIFICATE PE INSTRUCTIUNI 
SI DATE 


Asadar, un model teoretic mai realist, ar trebui sa introduca un nou 
parametru Pb, ca semnificând probabilitatea ca sa se lanseze în executie o 


instructiune de salt conditionat predictionat incorect. Noul model de automat va 


tranzitiona dintr-o stare in alta pentru o structura pipeline cu 4 stagii, dupa modelul 


de mai jos. 
Stare prez. Tranzitie Stare urm. 
3,0 Fetch 2,Ex.1 4,0 


4,1 


Fetch 2,Ex.2 3,0 


0,0 


Probab. tranz. 
P(1)(1-Pmem-Pb) 
P(1)Pmem 

P(1)Pb 

P(2) (1-Pmem-Pb)2 
P(2)(2Pmem(1- 
PmemPb)+Pmem2) 


P(2) (2 Pb(1-Pb) + Pb2) 


O verificare - fie si incompleta - a corectitudinii acestui model rezida in 


observatia ca adunând toate probabilitatile de tranzitie aferente acestei stari, suma 


este 1. De remarcat, fata de modelul anterior unde se putea considera cu o buna 


aproximare ca parametrii aferenti sunt cvasiindependenti, ca în acest caz parametrii 


Pb si Pmem depind unul de altul, adica de exemplu, daca la un moment dat 


P(linstr)=1, atunci avem Pb*Pmem=0. Desigur, complexitatea modelului creste 


considerabil în acest caz. Uzual, probabilitatea Pb < 15% , conform referintelor 


bibliografice [Per93, Yeh92]. 


O problema dificila dar necesara acestui demers, consta în determinarea unei 


relatii analitice pentru IRs, în cazul unui model echivalent cu cel anterior dar având 


busuri separate. Acest lucru este absolut necesar comparatiei. Pentru aceasta se 
prezinta urmatorul rationament: 

- daca P(linstr)=1 si Pb=0, atunci se poate executa o instructiune. 

- daca P(linstr)=1 si Pb=1, se executa branch-ul în tactul curent, iar apoi 
datorita golirii bufferului de prefetch nu se executa nici o instructiune, deci se 


executa în medie 0.5 instructiuni cu o buna aproximare. 
- daca P(2instr)=1 si (1-Pb)2=1, se executa 2 instructiuni 


- daca P(2instr)=1 si Pb2 + 2Pb =], atunci se executa în tactul curent 2 
instructiuni, iar în tactul urmator, datorita golirii bufferului de prefetch, nu se mai 
executa nici o instructiune, deci putem considera cu o buna aproximare ca se 
executa în medie 1 instructiune în aceasta situatie. 

În acest caz, pe baza celor de mai sus, cu o buna aproximatie, rata medie de 
procesare pentru o arhitectura cu busuri separate (IRsc) ar putea fi data de relatia: 

IRs = P(linstr) (1 - 0.5 Pb) + P(2instr) (3Pb2 - 2Pb + 2) (4.19) 

Pentru Pb=0, din relatia (4.19) se obtine relatia (4.13), ceea ce este corect, 


verificându-se generalizarea modelului precedent. 


4.2.2.1 REZULTATE OBTINUTE PE BAZA METODEI 


În figura urmatoare (fig.4.17), se prezinta comparativ ratele de procesare 
obtinute pentru o arhitectura Harvard si respectiv non-Harvard, pe baza modelelor 


teoretice dezvoltate în paragraful 4.2.2., pentru parametrii FR=2, IR=2 si IBS=4. 


Astfel pentru Pb = 20% si pentru valori tipice ale parametrului P(2instr) de 0.4 si 
respectiv 0.6, se obtine [Ru = 1.01 si IRs = 1.22 (crestere cu 20%), respectiv IRu = 
1.09 si IRs = 1.39 (crestere cu 27%). Pentru Pb = 5% si pentru aceleasi valori tipice 
ale lui P(2instr), se obtine [Ru = 1.15 si IRs = 1.34 (crestere cu 17%) respectiv [Ru 
= 1.22 si IRs = 1.52 (crestere cu 25%). De remarcat ca scaderea lui Pb determina 
performante superioare si totodata permite micsorarea decalajului de performanta 
între cele doua optiuni analizate. Totusi acest decalaj de performanta cuprins între 
17 si 27% este unul semnificativ, aceasta din cauza parametrilor FR, IR si IBS 


nefavorabili arhitecturii non-Harvard dupa cum am aratat într-un paragraf anterior. 


—@— IRu, Pb=0.2 
—{li—_ IRs, Pb=0.2 
—A— IRu, Pb=0.05 
— << IRs, Pb=0.05 


0.4 0.6 
P(2instr) 


Figura 4.17. Comparatie separate vs. unificate pt. Pb=20% respectiv Pb=5% (FR=2, IBS=4) 
În figura urmatoare (fig.4.18) se prezinta aceleasi performante comparative, 
de data aceasta însa cu parametrii FR = 4, IR = 2 si IBS = 8, mairealist alesi si care 


conduc la rezultate superioare. De asemenea s-a ales Pmem = 30%. Pentru aceleasi 


valori tipice ale lui P(2instr) de 0.4 si 0.6, am obtinut pentru Pb = 20%, IRu = 1.09 
si IRs = 1.22 (crestere cu 12%) si respectiv IRu = 1.21 si IRs = 1.39 (crestere cu 
15%). Pentru Pb = 5%, s-au obtinut IRu = 1.28 si IRs = 1.34 (crestere cu 5%), 
respectiv [Ru = 1.43 si IRs = 1.52 (crestere cu 6%). Asadar în acest caz diferentele 
de performanta intre arhitectura Harvard respectiv non-Harvard, devin mai mici. 
Iarasi de remarcat ca scaderea lui Pb determina micsorarea decalajului si important, 
cresterea gradului de paralelism P(2instr) determina la rândul sau marirea 
decalajului de performanta în favoarea arhitecturilor cu busuri separate I/D, ceea ce 
arata ca aceste arhitecturi unificate nu se preteaza totusi unor tehnici agresive de 


procesare paralela a instructiunilor. 
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Figura 4.18. Comparatie separate vs. unificate pt. Pb=20% respectiv Pb=5% (FR=4,IBS=8) 
În cele doua figuri urmatoare 4.19 si 4.20 se prezinta evolutia parametrului 


IBE pentru o arhitectura superscalara caracterizata de FR = IR = 2, IBS = 4 si 


respectiv pentru o alta având FR = 4, IR = 2, IBS = 8. În ambele cazuri am ales 
Pmem = 30%, tipic. Evolutia procentajului de timp cat bufferul de prefetch este 
gol, se prezinta pentru valori diferite si realiste ale parametrului Pb. Cum era si de 
asteptat, datorita parametrilor de proiectare FR, IR, IBS mai realist alesi in al doilea 


caz se obtin valori superioare pentru indicatorul IBE. 
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Figura 4.19. IBE [%] pt. diferite procentaje ale ramificatiilor în program (FR=2, IBS=4) 

Astfel, de exemplu, pentru Pb = 15% si P(2instr) = 0.6, valori tipice, in 
primul caz se obtine IBE = 27% iar î al doilea de 19.5%, ceea ce subliniaza înca o 
data importanta unei alegeri adecvate a parametrilor FR, IR, IBS. Interesant, 
cresterea lui Pb pare a contribui mai semnificativ la degradarea lui IBE în cel de-al 


doilea caz (FR = 4, IR = 2, IBS = 8). 
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Figura 4.20. IBE [%] pt. diferite procentaje ale ramificatiilor în program (FR=4, IBS=8) 

În figura care urmeaza (fig. 4.21), se prezinta într-un mod cantitativ, pentru o 
arhitectura non-Harvard cu FR = 4, IR = 2, IBS = 8 si Pmem = 30%, variatia 
performantei (IRu) functie de diferite valori tipice ale parametrului Pb. În acest caz 
de exemplu, pentru P(2instr) = 0.4 si Pb = 5% rezulta IRu = 1.28 iar pentru 
P(2instr) = 0.4 si PB = 20% se obtine IRu = 1.09, deci o scadere cu 17% a 
performantei, ceea ce nu este deloc surprinzator. De asemenea, P(2instr)>0.8, 


determina un salt brusc de performanta. 
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Figura 4.21. Performanta unificatelor pt. diferite procentaje ale ramificatiilor in program 


În continuare (fig. 4.22) se prezinta pentru o arhitectura non-Harvard având 
FR = 4, IR = 2, IBS = 8 si pentru un Pb = 0.1 tipic, variatia performantei functie de 


doua valori extreme, realiste, ale parametrului Pmem. 
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Figura 4.22. Performanta unificatelor pt. doua procentaje distincte ale instructiunilor cu referinta la 
memorie 


Interesant, o variatie de la 20% la 40% a lui Pmem nu produce o degradare 
semnificativa a performantei, ceea ce este semnificativ. Degradarea maxima a lui 
IRu este de la 1.65 la 1.53 instr./tact, adica de cca 7%. În realitate, diferenta medie 
de performanta pentru cei doi parametri Pmem este mult mai mica, de cca. 4%. 
Aceasta constituie înca o dovada ca o judicioasa alegere a parametrilor FR, IR si 
IBS poate masca puternic efectele negative de performanta pe care le implica 
coliziunile la busul unificat. 

În fine, urmatorul grafic prezentat în figura 4.23 pune în evidenta cresterea 
cantitativa a performantei datorata exclusiv cresterii parametrilor FR si IBS, pentru 
o arhitectura non-Harvard de procesor superscalar. Astfel, pentru P(2instr) = 0.4 se 
obtine [Ru = 1.21 respectiv 1.10 (crestere cu 10%), iar pentru P(2instr) = 0.6 se 
obtine IRu = 1.35 si respectiv 1.16, deci o crestere de 16%. Iarasi interesant, 
cresterea gradului de paralelism notat cu P(2instr) favorizeaza în acest caz al doilea 


model (FR = 4, IBS = 8) comparativ cu primul (FR = 2, IBS =4). 
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Figura 4.23. Performanta unificatelor pt. doua strategii de prefetch distincte 


În concluzie, o alegere adecvata a parametrilor FR, IR si IBS poate face din 
arhitecturile cu busuri unificate I/D o varianta atragatoare. De asemenea, scaderea 
parametrului Pb prin strategii performante de predictie precum si cresterea gradului 
de paralelism prin metode performante de scheduling static si dinamic, conduc la 
performante ridicate ale acestor arhitecturi considerate pâna acum ca fiind 
ineficiente în cadrul arhitecturilor MEM. 

O alta problema deosebit de interesanta si care se ridica este urmatoarea: pare 
evident ca un prefetch agresiv determina cresterea performantei procesorului. 
Ironia consta în faptul ca, acelasi prefetch în cazul predictiilor eronate ale branch- 
urilor, poate genera 2 fenomene nedorite: marirea inutila a ratei de miss în cache- 
uri si respectiv necesitatea golirii bufferului de prefetch si a anularii anumitor 


executii. Altfel spus, se aduc anticipat instructiuni inutile executiei, doar spre a fi 


golite din buffer. Acestea determina scaderea performantei procesorului. Exista 
putine abordari, daca totusi exista, ale acestei probleme, iar acest model poate 
raspunde la aceasta problema datorita generalitatii sale. 

În fine, toate aceste concluzii teoretice vor trebui comparate cu cele obtinute 
pe baza de simulare. Astfel, se va avea un control asupra acestor metode teoretice 
si se va putea stabili pâna la ce punct ele ramân realiste. Acesasta investigatie 
complexa bazata pe simulare va fi startata în continuare, în capitolul 5. Pe de alta 
parte, trebuie avut în vedere faptul ca si aceste modele teoretice ar putea implica la 


un moment dat o complexitate ridicata a calculului. În acest sens, complexitatea de 


calcul a acestui model este de ordinul O(N3). Asadar calculul devine relativ 
complex atunci când numarul de stari N creste simtitor dar oricum nesemnificativ 


în comparatie cu simularea software. 


4.3. UN MODEL ANALITIC DE EVALUARE GLOBALA A 
PERFORMANTEI CACHE-URILOR IN ARHITECTURILE 
SUPERSCALARE 


În cele ce urmeaza ne propunem determinarea unui model teoretic simplu de 
comparare a eficientei memoriilor cache unificate respectiv separate, implementate 
într-o arhitectura RISC superscalara. Pâna în acest moment am abordat aceasta 
problema în mod comparativ, exclusiv din punct de vedere al coliziunilor la 


busurile unificate. Demersul nostru se va baza pe un indicator de performanta 


specific global, numit timp mediu de acces la cache. În final, acest indicator va 
trebui sa inglobeze ratele de miss specifice, procesul de prefetch din I-Cache iar în 
cazul cache-urilor unificate si procesele de coliziune implicate. Asadar, se incearca 
inglobarea intr-un singur indicator, pe baza teoretica, a principalelor fenomene 
legate de problematica memoriilor cache separate si respectiv unificate. 

Vom dezvolta asadar doi indicatori: Ts si Tu cu semnificatia de timp mediu 
de acces la cache-urile separate respectiv unificate. Comparatia asupra 
performantelor se va putea face pe baza maximului dintre cei doi parametri astfel: 
daca max (Ts, Tu) = Tu, atunci separatele sunt mai eficiente, altfel unificatele sunt 
mai eficiente. Rata medie de miss într-o arhitectura de procesor cu memorii cache 
separate pe spatiile de instructiuni si date este data de relatia: 

MRs = IC MRic + DC MRdc, (4.20) 

unde: 

IC - probabilitatea statistica de acces la spatiul de instructiuni; 

DC - probabilitatea statistica de acces la spatiul de date; 

MRic - rata medie de miss în memoriile cache de instructiuni; 

MRdc - rata medie de miss în memoriile cache de date. 

Este evident ca IC + DC = 1 si ca practic IC > DC. Valori tipice pentru acesti 
parametri sunt: IC = 75%, MRic = 0.02% - 3% si MRdc = 2.88% - 24%. De 
observat ca DC = Pmem / (1 + Pmem) .Notând cu MRu rata de miss într-o 


arhitectura de procesor cu memorii cache unificate, simulari laborioase au aratat ca 


MRs > MRu in medie cu cca 10% [Hen96]. Asadar, din punct de vedere al ratei de 
hit precum si al ratei de utilizare, cele unificate sunt mai eficiente. Timpul mediu 
de acces exprimat in numar de impulsuri de tact in ipoteza ca in caz de hit orice 
acces la cache dureaza un singur tact, este: 

Ts = IC( + MRic N) + DC( + MRdc N) = 1 + N MRs (4.21) 
unde N reprezinta numarul de tacti necesari accesului la memoria principala in caz 
de miss în cache-uri. Tipic, N ia valori cuprinse între 10 - 20. În mod analog 
rezulta: 

Tu = 1+ N MRu (4.22) 

Cum MRs > MRu, rezulta ca Ts > Tu, asadar pare o dovada clara a 
superioritatii celor unificate. Realitatea nu este aceasta, dimpotriva, datorita 
proceselor de coliziune pe care unificatele le implica si care genereaza asteptari în 
accesele la cache-uri. Putem deci considera în plus, ca se introduc în accesarea 
cache-urilor, datorita proceselor de coliziune, un numar mediu de M tacti 
suplimentari, M =1,2,.... Problema care se pune este: în caz de conflict se vor 
introduce asteptari în accesele la I-Cache sau la D-Cache ? În primul caz timpul de 
acces va fi: 

Tu = IC( +M +MRu N) + DC( +MRu N) =1 +N MRu+ICM — (4.23) 

În al doilea caz, in mod analog analog, Tu devine: 


Tu = 1+ MRu N + DC M (4.24) 


Cum IC > DC din relatiile anterioare rezulta ca pare a fi mai bine ca in caz de 
conflict sa dam prioritate acceselor la I-Cache. Prin M am notat numarul mediu de 
tacti suplimentari introdusi de catre procesele de coliziune în accesul la Cache 
respectiv la D-Cache. În [Hen96, pagina 385] se adopta ca model de evaluare a 
performantei cel dat de relatia (4.24 ) pe motivul ca acesta minimizeaza Tu. Acest 
model este gresit si incomplet dupa cum vom arata în continuare, chiar daca din 
punct de vedere pur algebric pare cel optim. Realitatea este ca în practica se prefera 
a se da prioritate acceselor la D-Cache în caz de conflict [Rya93, IBM93, Weis94]. 
În continuare vom lamuri de ce se întâmpla acest lucru si pe baza analitica. 

Daca am da prioritate acceselor la FCache, este posibil ca o instructiune 
LOAD / STORE aflata în bufferul de prefetch sa astepte indefinit lansarea in 
executie (pâna când acest buffer s-ar umple). Acest lucru este inacceptabil, întrucât 
în fond nu ne intereseaza atât minimizarea Tu, ci mai important, cresterea ratei de 
procesare a instructiunilor care este parametrul ce înglobeaza toate procesele 
posibile. Modelul prezentat nu are in vedere procesul de prefetch implementat in 
majoritatea procesoarelor cu scopul suprapunerii aducerii instructiunilor cu 
executia lor pipeline-izata. Cu oarecare aproximație putem considera ca t% din 
timpul total, accesele la I-Cache sunt transparente din punct de vedere al 
performantei, unde t% reprezinta procentajul de timp cât numarul instructiunilor 
din bufferul de prefetch este mai mare decât rata maxima de lansare în executie a 


instructiunilor. Altfel spus, t% reprezinta procentajul de timp cât procesorul detine 


suficiente instructiuni in bufferul de prefetch a. î. sa proceseze la o rata de executie 
maxima. Cu o buna aproximare sar putea considera ca t reprezinta acuratetea 
predictiei branch-urilor. Asadar, numai (1 - t) % din accesele la I-Cache se "simt" 
din punct de vedere al ratei de procesare a instructiunilor. 

Printre altele, t este functie de rata de fetch (FR), rata maxima de lansare în 
executie (IR) si capacitatea bufferului de prefetch (IBS). O alegere optimala a 
acestor 3 parametri în sensul sugerat anterior precum si o strategie agresiva de 
prefetch, vor maximiza parametrul t si deci rata de procesare medie (IR). Desigur 
ca parametrul t depinde direct si de acuratetea predictiei branch-urilor întrucât în 
caz de predictie eronata bufferul de prefetch trebuie golit. Cum aceste branch-uri 
sunt predictionate corect prin scheme clasice de tip BTB (Branch Target Buffer), în 
proportii de peste 90% (schemele adaptive de predictionare comunica succese în 
proportie de 97% [Yeh92] ), rezulta ca cel mult 10% din timp bufferul de prefetch 
este gol. Putem deci considera o valoare maxima pentru parametrul (1 - t) cuprinsa 
între 0.2 - 0.4 „în cazuri clar defavorabile pentru cele unificate. Având în vedere 
performantele actuale obtinute în predictia branch- urilor, parametrul t poate fi 
considerat ca variind între O si 0.1. 

Daca cele de mai sus le introducem în relatia (4.23 ) obtinem : 

Tu=(1 -t) IC 1 +M+MRuN) + DC (1 + MRu N) (4.25) 

Daca cele de mai sus le introducem in relatia(4.24) vom obtine urmatoarea 


formula: 


Tu=(1 - t) IC (1 + MRu N) + DC (1 +M +MRu N) (4.26) 

Acum devine clar si din punct de vedere formal, de ce se prefera in caz de 
conflict sa se dea prioritate acceselor la D-Cache, întrucât relatia (4.25 ) 
minimizeaza parametrul de performanta Tu, care acum trebuie vazut ca un 
indicator analitic de performanta si nu ca timp de acces in sensul strict. Prin urmare 
relatia (4.21 ) devine: 

Ts=(1 - t) IC (1 + MRic N) + DC (1 + MRdc N) (4.27) 

Desigur, parametrii MRdc, MRic si MRu pot fi minimizati prin cresterea 
capacitatii cache-urilor si respectiv prin marirea gradului de asociativitate al 
acestora [Hen96]. În concluzie la cele de pâna acum, o comparare între cele doua 
tipuri de arhitecturi cache s-ar putea face pe baza relatiilor (4.25) si (4.27), care 
desi derivate din modele analitice simple, le consideram ca fiind realiste. Avantajul 
lor dupa cum aratam, poate consta în evitarea unor simulari laborioase în stabilirea 
arhitecturilor optimale de memorii cache într-o anumita arhitectura. 

În final, vom face o evaluare numerica pe baza relatiilor stabilite. Vom 
evalua o arhitectura separata avînd 2 Ko I-Cache si 2 Ko D-Cache cu o arhitectura 
unificata având 4 Ko. Memoriile cache sunt de tip "direct mapped". Preluat din 
[Hen96], vom considera MRic = 0.0226, MRdc = 0.2057, MRu = 0.0724, IC = 
0.75 si DC = 0.25. De asemenea, vom considera M = 1, N = 10 si t = 0.7 
(defavorabil pentru cache-urile unificate). În baza relatiilor (4.25) si (4.27 ), se 


obtine Ts = 1.0400 si Tu = 1.0439 având asadar performante comparabile. În 


aceleasi conditii, dar alegand t = 0.75 se obtine Ts = 1.0951 si Tu = 0.9417, deci un 
avantaj pentru cele unificate. Maximizarea lui t este deci esentiala in cresterea 
performantei arhitecturlior unificate. Aceasta problema merita cred dezvoltata in 
continuare. 

În concluzie, din nou, în ciuda parerii cvasiunanime, arhitecturile de memorii 
cache unificate pot avea în anumite conditii performante comparabile cu cele 
separate, oferind în plus anumite simplificari în hardware. Desigur ca pentru o 
concluzie ferma sunt necesare investigatii ulterioare atât pe plan teoretic cât si pe 
baza de simulare a comportarii acestor arhitecturi pe trace-uri ale unor benchmark- 
uri consacrate. Acesta este de altfel pasul urmator al cercetarii noastre din aceasta 
lucrare si care va da un raspuns definitiv la aceasta problema. Eficienta cache -urilor 
unificate este direct legata de îmbunatatirea tehnicilor de prefetch, de predictie a 


branch-urilor si de reducere a efectului defavorabil aferent proceselor de coliziune. 


4.4. TEHNICI DE PREFETCH PERFORMANTE ÎN ARHITECTURILE 
MEM 


Dificultatea majora pentru implementarea unor tehnici de prefetch cât nai 
agresive o constituie instructiunile de ramificatie care modifica secventialitatea 
programului. Întrucât performanta acestor tehnici de prefetch afecteaza direct 


performanta procesoarelor MEM în general si în special pe cea a cache-urilor 


separate/unificate, vom prezenta succint cele mai avansate realizari pe aceasta tema 
la ora actuala [Wal96, Tem96, Par96, Hen96]. 

O solutie de referinta in opinia mea este cea propusa si analizata de catre Park 
si colaboratori [Par96] si se bazeaza pe conceptul novator de cache NRP (Non 
Referenced Prefetch). În principiu se propune ca pe lânga memoria I-Cache sa se 
mai implementeze o alta memorie cache numita NRP. Solutia are în vedere 
prefetch-ul ambelor ramuri în cazul unor ramificatii conditionate. Blocurile aduse 
anticipat se memoreaza în bufferul de instructiuni IB. În momentul în care ramura 
de ramificatie este determinata, blocul (instructiunea) adus inutil în IB va fi 
memorat în NRP-Cache. Acest mecanism reduce posibilitatea unor viitoare miss- 
uri în cache, în cazul în care instructiunea de ramifcatie anterior executata va avea 
o comportare complementara. Dintr-un anumit punct de vedere solutia este 
similara cu aceea data de conceptul de "cache victima” sau mai nou, cu cel de 
"cache victima de tip selectiv” [Sti94], asupra carora vom reveni în capitolul 
urmator. Structura memoriilor cache în acest caz, va fi cea prezentata în figura 
4.24. Bitul V are rol de validare a informatiei în cache (accese DMA, conectare în 
sisteme multimicro, etc.), iar bitul T determina daca un bloc din IB va fi memorat 
în NRP-Cache sau in FCache. La prefetch-ul unui bloc in IB, initial bitul T este 
setat. Daca respectivul bloc va fi procesat de catre CPU, bitul T va fi resetat. Daca 
in momentul determinarii ramurii procesate bitul T = 1, atunci blocul respectiv se 


va evacua in NRP-Cache. Desigur ca mecanismul NRP functioneaza in stransa 


legatura cu predictorul hardware de tip BTB. Mecanismul de prefetch se 


declanseaza numai daca blocul respectiv nu se afla în I-Cache, NRP-Cache sau IB. 
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Figura 4.24. Arhitectura NRP Cache 

Cu un NRP-Cache având capacitatea 1/8 din cea a I-Cache, ambele de tip 
mapare directa, se arata ca traficul la memoria principala se reduce cu 50-112% 
fata de o arhitectura fara NRP-Cache. De asemenea, aceasta solutie reduce 
semnificativ rata de miss in Cache determinând deci o îmbunatatire a timpului 
mediu de acces [Par96]. 

O alta solutie relativ recenta [Wal96], are în vedere depasirea unei limitari 
fundamentale relativa la rata de prefetch în procesoarele superscalare. Daca p este 
probabilitatea ca o instructiune sa determine o ramificatie, atunci rata de prefetch 


medie este limitata la valoarea 1/p. Solutia se bazeaza pe conceptul nou introdus 


numit DBTB (Dual BTB), derivat din conceptul de predictor BTB introdus de Lee 
si Smith [Lee84]. Fiind dat PC-ul curent, DBTB-ul predictioneaza adresele de 
inceput ale urmatoarelor doua instructiuni multiple ce vor fi executate. Avand deci 
in vedere ca se predictioneaza in avans doua PC-uri, este necesat un I-Cache de tip 
biport si cu autoaliniere pentru a putea permite doua citiri simultane. Astfel, prima 
instructiune multipla predictionata va putea contine o instructiune primitiva de 
transfer fara a fi necesari doi cicli pentru accesarea din FCache. Prin aceasta 
tehnica noua, rata de prefetch va fi limitata superior de valoarea 2/p, ceea ce este 
semnificativ. Se arata ca astfel pot deveni realiste rate de prefetch de 14 instructiuni 
primitve simultan ceea ce este deosebit de performant. 

În concluzie, îmbunatatirea tehnicilor de prefech în arhitecturile MEM sunt 
determinate esential de 3 aspecte: acuratetea predictiilor hardware, arhitectura 
memoriilor cache si implementarea unor suporturi hardware adecvate pentru 
prefetch. Solutiile arhitecturale actuale în acest domeniu par a fi deosebit de 
agresive si eficiente, acesta constituind un puternic argument în favoarea 


realismului analizelor noastre realizate pâna în acest moment. 


4.5. CONSIDERATII PRIVIND ALEGEREA RATEI DE PROCESARE SI A 
NUMARULUI DE RESURSE ÎNTR-O ARHITECTURA ILP 


Sa consideram acum un procesor cu executii multiple ale instructiunilor, de 
tip RISC. Vom partitiona setul de instructiuni G al acestui procesor in s tipuri 


reprezentative, ortogonale, astfel: 

G = {]j(ml, nl), Ip(m2, n2), ..., Is(ms, ns)} (4.28) 

Am notat prin: 

mk = numarul acceselor simultane de citire permise dintr-un set fizic de 
registri generali pentru o instructiune de tipul I. Uzual mk = 0, 1, 2, pentru oricare 
k=1,..,s. 

nk = numarul acceselor simultane de scriere (WB) permise într-un anumit set 
de registri generali pentru o instructiune de tipul  Uzual nk = 0, 1 oricare k = 1, 
seg Ss 

Pentru ca tipurile de instructiuni I, sa fie ortogonale si deci partitionarea 
consistenta este necesara indeplinirea conditiei: 

(mi, ni) + (mj, nj), V)i +j, je {1,..., s} (4.29) 

De asemenea notam: 


Pk = probabilitatea de lansare in executie a unei instructiunide tipul k (mk, 


nk). Este evident ca avem valabila relatia de normalizare: 


$ Pk=1 (4.30) 
k=1 


IR = rata medie de procesare, în general impusa prin proiectarea arhitecturii 


de procesor [instr./tact]. 


N = numarul de seturi de registri generali. Mentionam ca este necesar ca si 
continutul acestor seturi de registri sa fie permanent acelasi pentru a respecta 
modelul clasic de programare. Presupunem, fara a reduce din generalitate, ca un set 
permite doua citiri simultane in faza ID din pipeline. 

M = numarul de scrieri simultane permis in faza WB a structurii pipeline. 
Uzual se alege M = 2 - 4. Marirea lui M produce complicatii hardware si datorita 
"time-sharing"-ului perioadei de tact necesare pentru scriere in faza WB si implica 
marirea perioadei de tact a procesorului. De exemplu, microprocesorul superscalar 
AMD-KS compatibil Pentium, are N = 4 si M = 4 [Cri96]. 

În continuare ne propunem sa determinam câteva conditii relative la alegerea 
optimala a parametrilor N si IR, prin prisma unui optim performanta - pret. Putem 
considera deci ca numarul mediu de citiri / tact impuse de catre o instructiune de 
tipul I, este: 

mk 

Ncitiri (k) = mk(1 - )Y Xki), (431), 

i=] 

unde: 


Xki = probabilitatea ca o instructiune de tipul I, sa obtina in statia de 


rezervare aferenta un numar de i operanzi sursa prin tehnici de forwarding, fara a 


mai accesa deci un set de registri generali. Desigur ca avem indeplinita identitatea: 


mk 
1- 9 Xki =Xko, (4.32), 
i=l 


unde: 

Xko = probabilitatea ca o instructiune de tipul I, sa nu obtina nici un 
operand sursa prin forwarding, necesitând deci mk accese de citire la un set de 
registri generali. Asadar: 

Ncitiri(k) = mk * Xko (4.33) 

Din considerente de obtinere a unei utilizari cât mai ridicate a seturilor de 
registri la citire în faza ID si totodata de obtinere a unei rate medii de procesare IR 


ridicate, devine necesara impunerea urmatoarei conditii la citirea din registri: 


IR* È. Pk*mk *Xko <2N (4.34) 


k=1 


Din motive analoage, in faza de scriere WB este necesar ca: 


IR* È Pk*nk < M (4.35) 


k=1 
Considerând ca exista Ok unitati functionale aferente executiei instructiunilor 


de tip Ip, k = 1, ..., s, numarul total de unitati functionale (U) este: 


U=} ok (4.36) 
k=l 


Desigur este necesara indeplinirea conditiilor: 
IR * Pk < Ok pentru oricare k = 1, ..., s adica: 


IR<U (4.37) 


Este deci necesar in alegerea parametrilor IR, N, M si Ok sa se tina cont ca 
toate relatiile anterior stabilite sa fie satisfacute in vederea unei proiectari adecvate. 
În [Wal96] se arata ca rata de fetch a instructiunilor (FR) într-o arhitectura MEM 
este fundamental limitata prin relatia: 

FR<1/p, (4.38), 
unde: 

p = probabilitatea unei ramificatii in program. 

Printr-o arhitectura inteligenta de predictie a branch-urilor numita DBTB 
(Dual BTB), anterior schitata, se arata ca parametrul FR ar putea fi semnificativ 
marit, noua limitare devenind [Wal96]: 

FR<2/p (4.39) 

Cert este deci ca aceste limitari sunt cu atât mai mult valabile si pentru 
parametrul IR. Din cele prezentate pana acum rezulta deci ca este necesara 


indeplinirea urmatoarelor inegalitati: 


IR < Min { 1/p, M/ oy Pk*nk)) (4.40) si 
k=1 
N > (IR/2) * )° Pk mk * Xko (4.41) 
k=1 


Aceste relatii pot fi deosebit de utile in alegerea optimala a parametrilor IR si 


N. În plus, prin intermediul lor se pot evita simulari software extrem de laborioase 


si enorme consumatoare de timp. Ca un exemplu, aplicând aceste relatii pe 
urmatoarele date initiale de proiectare, considerate ca fiind realiste: 

G= (IQ, 1) - instr. ALU, DC, 1) - LOAD, 13(2, 0) - STORE, I4 (1, 0) - 
BRANCH}, P = 0.125 [Wal96]; Totodata: P1 = 0.5, P2 = P3 = 0.15, P4 = 0.2 
[Hen96] 

De asemenea alegând M = 2, Xlo = 0.8 si X20 = X30 = X40 = 0.3 [Joh91], 
se obtine IR= 3 si N = 2, rezultate deosebit de realiste si care pot fi regasite usor in 
multe implementari uzuale. În concluzie la acest paragraf, s-au obtinut câteva 
relatii analitice originale, deduse pe baza proceselor de coliziune aferente unei 
arhitecturi MEM si care trebuie sa fie îndeplinite prin orice proiectare realista a 
unor asemenea arhitecturi. Ele pot da indicatii rapide si deosebit de utile în faza de 


pre - proiectare a arhitecturii. 


5. EVALUAREA SI OPTIMIZAREA CACHE-URILOR ÎN CADRUL 
PROCESOARELOR MEM 


5.1. SIMULATOR PENTRU O ARHITECTURA SUPERSCALARA 
PARAMETRIZABILA. PRINCIPIILE SIMULARII. 


În acest prim paragraf se va prezenta succint un simulator scris în Borland 
C++ 3.1, dezvoltat special cu scopul de a furniza rezultate semnificative relative la 


performanta si structura optimala a memoriilor cache cu mapare directa, integrate 


într-o arhitectura superscalara parametrizabila. De asemenea se vor prezenta 
principiile si metodologia care stau la baza simularilor realizate. Simulatorul 
permite atât analiza unor arhitecturi superscalare având busuri si cache-uri separate 
pe spatiile de instructiuni si date (Harvard) cât si a unor arhitecturi cu busuri si 
cache-uri unificate (non-Harvard sau Princeton). Am considerat ca printr-o 
asemenea simulare se pot obtine rezultate realiste relative la arhitecturile 
superscalare Harvard comparativ cu cele non-Harvard. Totodata, simularea permite 
sa se verifice analizele teoretice realizate pâna în acest moment (v. cap. 4), referitor 
la aceasta problema. Se mentioneaza înca odata, ca dupa stiinta autorului, bazata pe 
o laborioasa si atenta cercetare bibliografica, precum si pe discutii cu specialisti de 
prestigiu din domeniu, nu exista înca abordari teoretice sau pe baza de simulare 


referitor la aceasta problema. 


Programul simulator dezvoltat, va procesa trace-uri HSA (Hatfield 
Superscalar Architecture) obtinute dintr-un alt simulator, special conceput la 
Universitatea din Hertfordshire, U.K. [Col95]. Acest simulator însa, nu abordeaza 
problema cache-urilor si deci cu atât mai putin a celor unificate. Se poate deci 
considera prezenta contributie ca fiind integrata in efortul de dezvoltare al 
arhitecturii HSA, fapt de altfel institutionalizat prin colaborari stiintifice oficiale, 
între autor si grupul de arhitecturi avansate de la Hertfordshire. O problema 
deschisa care va fi abordata prin simulare, dupa abordarea analitica din capitolul 
anterior, consta în determinarea raportului de performanta între arhitecturile de 
memorie Harvard si respectiv non-Harvard (Princeton), integrate într-un procesor 
superscalar. De asemenea, se vor determina într-un mod original, parametrii optimi 
de proiectare pentru aceste doua tipuri de arhitecturi cache. Momentan, dupa cum 
am mai precizat, simulatorul are în vedere doar cache-urile cu mapare directa, cele 
mai pretabile în a fi integrate într-un microprocesor [Rya93, Joh91], dar pe viitor 
se intentioneaza dezvoltarea simulatorului si cu arhitecturi cache având diferite 
grade de asociativitate, mai ales ca implementarea acestora pe scara larga în 
viitorul apropiat pare o certitudine. 

Principalii parametri ai arhitecturii, alesi în deplina concordanta cu nivelul 
tehnologic al implementarilor actuale (anul 1998), sunt urmatorii: 

- FR (Fetch Rate) - rata de fetch instructiune din I-Cache, poate fi de 4, 8 sau 


16 instructiuni; 


- IBS (Instruction Buffer Size) - capacitatea bufferului de prefetch (IB) care 
poate fi de 4, 8, 16, 32 sau 64 instructiuni; 

- capacitatea memoriilor cache care variaza intre 64 cuvinte si 16 Kcuvinte. 
Aceste capacitati relativ mici ale memoriilor cache se datoreaza particularitatilor 
benchmark-urilor Stanford utilizate. Acestea folosesc o zona restrânsa de 
instructiuni, limitata la cca. 2 Ko si o zona de date mai mare dar mai "rarefiata”, 
care se întinde pe un spatiu de cca 24 Ko. 

Structura de pricipiu a arhitecturii superscalare non-Harvard care a fost 
simulata este cea din figura (Figura5.1). Structura Harvard simulata este similara, 


doar ca detine busuri si cache-uri separate pe spatiile de instructiuni si date. 


Memorie 
principala 


bus 
Cache instructiuni Decodificare 
si date instructiuni 


unificat P 3: 
instructiuni si unitati 


17D (1B) functionale 


date (L/S) 


Figura 5.1. Schema bloc de principiu a arhitecturii superscalare Princeton simulate 


Un cuvînt din memoria cache va contine doua câmpuri: un câmp de tag si un 
bit de validare V. Câmpul de tag contine blocul din memoria principala actualizat 
în cuvântul din cache de la indexul curent, iar bitul V valideaza informatia din 
cache în sensul în care, initial, fiecare cuvînt din cache va fi considerat invalid pâna 
la prima actualizare a sa din memoria principala. Memoria principala se acceseaza 
numai la miss în cache si va avea latente parametrizabile cuprinse între 10-20 tacti 
procesor (realist la nivelul performantelor tehnologiilor actuale). La miss în cache, 
trebuie deci introduse penalizari corespunzatoare în numarul tactilor de executie. În 
cazul acceselor la spatiul de date, se introduc penalizari numai pentru instructiunile 
LOAD, în cazul instructiunilor STORE nemaifiind nevoie datorita procesorului de 
iesire specializat (DWB) considerat pe moment idealizat si a bufferelor aferente 
(vezi cap2, 3). Asadar în aceasta faza a cercetarii scrierea s-a idealizat doar din 
motive legate de claritatea expunerii, oricum îngreunata de multitudinea 
caracteristicilor arhitecturale considerate. În paragraful urmator însa, se vor 
prezenta pe scurt câteva rezultate care se bazeaza pe o modelare interesanta si 
realista a acestor procese de scriere în spatiul de date. S-a considerat în mod realist 
ca este posibila executia simultana a oricaror doua instructiuni cu referire la 
memorie cu restrictia ca adresele lor de acces sa fie diferite (cache biport pe date). 
Având în vedere ca se lucreaza pe trace-uri, aceasta analiza antialias perfecta este 


evident posibila. Întrucât simularea se face pe baza trace-urilor HSA ale 


benchmark-urilor Stanford, s-a presupus o predictie perfecta a branch-urilor în 
cadrul simulari. 

Cele 8 benchmarkuri Stanford scrise în C, au fost compilate special pentru 
arhitectura HSA utilizând compilatorul Gnu CC (sub Linux), rezultând programele 
obiect HSA. Acestea se întind pe un spatiu de cod mai mic de 600 instructiuni 
HSA iar spatiul de date utilizat nu depaseste dupa cum am mai mentionat, 24 ko. 
Programele obiect HSA la rândul lor, au fost procesate cu un simulator special 
[Col95], care a generat trace-urile aferente. Un trace reprezinta un program masina 
obtinut în urma executiei sale, adica un fisier continând în fapt toate instructiunile 
masina în ordinea rularii lor, împreuna cu adresele acestora. Aceste trace-uri HSA 
sunt disponibile din simulatorul HSA [Col95] sub o forma speciala din motive de 
economie de spatiu pe disc si ele contin practic doar instructiunile de LOAD (L), 
STORE (S) si BRANCH (B-numai cele care au provocat într-adevar salt), in 
ordinea procesarii lor în cadrul programului respectiv, fiecare cu PC-ul sau si cu 
adresa efectiva corespunzatoare (de salt - B sau de acces la data - L/S). Chiar si în 
aceasta forma, un asemenea fisier trace ocupa între 2-4 Mo, el continând practic 
câteva sute de mii de instructiuni ce au fost executate (între 72.000 si 800.000 de 
instructiuni masina în cazul celor utilizate aici). Mai jos, se prezinta ca exemplu o 
portiune din trace-ul bubble.trc precum si o descriere succinta a benchmarkurilor 
utilizate în cercetare. 


B 45 27 B27 9 L 10 4564 S 14 4564 B 17 28 


S 32 4400 L33 4552 B 35 38 L 38 4556 B 40 42 


B45 27 B27 9 L 10 4564 S 14 4564 B 17 28 


S 32 4404 L 33 4552 B 35 38 L 38 4556 B 40 42 


Tabelul 5.1.Caracteristicile benchmark-urilor Stanford 


Benchmark Total instr. Descriere bench 
puzzle 804.620 Rezolva o problema de "puzzle" 
Sortare tablou prin metoda "bulelor" 
matrix 231.814 Inmultiri de matrici 


permute 355.643 Calcul recursiv de permutari 


queens 206.420 Problema de sah a celor 8 regine 


sort 72.101 Sortare rapida a unui tablou aleator (quick 


sort) 


251.149 Problema turnurilor din Hanoi (recursiva) 
136.040 Sortare pe arbori binari 


Este acum evident, ca prin procesarea unui asemenea trace, avand in vedere 


ca se dispune si de programul obiect HSA generat prin compilarea benchmarkului 
scris in C, se pot simula in mod realist, procesele legate de memoriile cache, 
predictorul hardware de ramificatii, etc., integrate într-un procesor paralel. 
Implementarea simulatorului a fost facuta considerând urmatoarele: 

- se aduc FR instructiuni din memorie în IB daca exista un spatiu disponibil 
în IB mai mare sau egal cu FR; 

- executia instructiunilor se face In Order, eludând deci complicatii hardware 
legate de modelarea si simularea unor algoritmi tip Tomasulo [Col95, Ste96]; 

- nu pot fi lansate în executie decât maxim doua instructiuni cu referire la 


memorie în conditiile în care adresele lor de acces sunt diferite (antialias); 


- în cazul exclusiv al arhitecturii cache de tip non - Harvard, daca în tactul 
curent se lanseaza în executie cel putin o instructiune LOAD / STORE, nu se 
declanseaza aducerea de instructiuni din cauza coliziunilor implicate (nu se pt 
aduce decât exact FR instructiuni din cache, din motive de aliniere adrese); 

- daca apare miss în spatiul de instructiuni pe perioada "lunga" a accesarii 
memoriei principale, se vor executa în continuare instructiuni din IB, cu conditia sa 
nu fie cu referire la memorie. În schimb, prefetch-ul va fi "inghetat" pe aceasta 
perioada ("blocking cache"). 

- într-o prima faza nu s-au considerat hazardurile de date între instructiunile 
lansate în executie din bufferul de prefetch întrucât problema studiata este cu totul 
alta si de asemenea s-a considerat latenta de executie a tuturor instructiunilor egala 
cu un tact, pentru a nu complica simularea. Ulterior, au fost modelate si simulate si 
aceste aspecte, dupa cum se va constata. 

Bufferul de prefetch (IB - Instruction Buffer) este implementat sub forma 
unei stive de tip FIFO (First In First Out), facilitând astfel operatiile de fetch 
instructiune (tail) si respectiv lansare in executie (head), care se realizeaza in 
fiecare ciclu al simularii. Cuvintele din IB contin 3 câmpuri: 

- tip: tipul instructiunii (B- Branch, L- LOAD, S-STORE, O- Alta) 


- adresa_instr: adresa instructiunii din program (PC-ul aferent) 


-adresa_urmat: adresa urmatoarei instructiuni din program (pt. instr. tip B si 
O) respectiv adresa "tinta" (target) de memorie pentru instructiunile LOAD / 
STORE 

Daca adresa urmatoare a unei instructiuni de salt (B) este una nealiniata cu 
FR, se va alinia si se va aduce noua instructiune multipla de la adresa aliniata, 
considerându-se astfel o implementare cache realista, în care accesele pot fi 
realizate doar la adrese multiplu de FR. Evident ca în acest caz, instructiunile inutil 
aduse, nu se vor lansa si contoriza în procesare. Executia simulatorului se face în 
urmatorii pasi succesivi: 

]. Solicitare parametri de intrare ai structurii superscalare si anume: rata de 
fetch (FR), dimensiune IB, rata maxima de lansare în executie a instructiunilor din 
bufferul de prefetch (IRmax), capacitate cache-uri, nume fisier trace utilizat (*.trc), 
numar tacte penalizare la miss în cache (N), etc. 

2. Creare fisier care simuleaza functionarea cache-ului (CACHE.DM) si 
initializare cache ( peste tot bit V si TAG=0). 

3. Lansare în executie a procesarii trace-ului 

- se verifica conflictele LOAD / STORE din zona de "issue teoretic” (egala 
cu IRmax) din IB. 

- daca în zona de "issue real"( numar instr. lansate anterior) din IB nu au 
existat instructiuni LOAD / STORE, atunci se va executa fetch instructiune, în 


ipoteza ca spatiul disponibil din IB o permite. Instructiunile vor fi citite din fisierul 


trace respectând logica de program. În caz de miss în cache, se penalizeaza timpul 
de executie si daca este posibil se vor executa în continuare instructiuni din IB. 

- daca în zona de "issue real", au existat instructiuni LOAD / STORE, se 
initiaza doar lansarea în executie a instructiunilor, cu penalizare a performantelor 
în caz de miss. Din motive de conflict, în acest caz nu este posibil prefetch-ul 
simultan. 

Simulatorul implementat genereaza urmatoarele rezultate , considerate ca 
fiind deosebit de importante pentru analiza propusa: 

- numar de instructiuni procesate, numar total de tacte, rata medie de 
procesare (IR) 

- rata de hit/ miss în cache-uri 

- procentajul din timpul total cat IB este gol (IBE%) 

- procentajul instructiunilor LOAD / STORE din trace 

- procentajul fetch-urilor de instructiuni raportat la timpul total de executie 

- procentajul din numarul tactelor cât exista alias-uri la memorie, etc. 

În ciuda predictiei perfecte a branch-urilor, indicatorul IBE nu este trivial 
datorita posibilitatii aparitiei miss-urilor în cache-uri si latentelor ridicate ale 
memoriei principale (N), care pot conduce la golirea bufferului IB. Toate aceste 
rezultate sunt afisate pe monitor si scrise într-un fisier (REZULT.SIM), 
permitându-se astfel prelucrarea lor ulterioara. Eventuale viitoare dezvoltari ale 


acestei cercetari pot avea în vedere implementarea unor cache-uri cu un grad sporit 


de asociativitate. In continuare se prezinta câteva dintre rezultatele originale 
obtinute precum si o analiza a acestora prin prisma unor obiective vizând 
proiectarea optimala si evaluarea de performanta. De asemenea, se va concluziona 
în ce masura modelele analitice dezvoltate pâna în acest moment (capitolul 4) 


corespund concluziilor rezultate din aceste laborioase simulari. 


5.2. REZULTATE OBTINUTE PRIN SIMULARE. ANALIZA SI 
CONCLUZII 


Simulatorul anterior prezentat a fost exploatat utilizând trace-uri ale 
benchmark-urilor Stanford, consacrate în acest domeniu. În tabelul urmator 
(tabelul 5.2), se prezinta distributia instructiunilor cu referire la memorie si 
procentajele acceselor în spatiile de instructiuni (IC %) si date (Pmem %), în cadrul 


acestor benchmark-uri. 


Tabelul 5.2. Caracteristicile benchmark-urilor d.p.d.v. al acceselor la spatiile de instructiuni si 
date 


Benchmark Pmem % IC % 
Bubble 30% 75% 


Matrix 29% 75% 


Perm 40% 70% 


Puzzle 17% 85% 


Se remarca reprezentativitatea benchmark-urilor Stanford si din acest punct 
de vedere [Mil89, Ste96]. O problema procedurala care se ridica este: cum 
agregam indicatorii de performanta obtinuti pentru fiece benchmark in parte (Ik), 
într-unul global (G), cât mai judicios ?. Poate ca o solutie teoretica ar consta in 


relatia ponderata: 


N 
G= } ok * Ik (5.1) 


k=1 

Prin @k am notat "ponderea" asociata benchmarkului k ("clasei de aplicatii 
echivalente”), pe timpul de lucru al unui utilizator virtual "reprezentativ". Cum 
acest lucru este practic imposibil de stabilit în mod practic, am preferat metrici de 
evaluare moderati, de tip medii armonice, sau aritmetice acolo unde este cazul. În 
continuare se prezinta câteva dintre rezultatele experimentale obtinute, în scopul 
unei comparatii pe baza de simulare între arhitecturile cache unificate si respectiv 
cele separate. Se precizeaza ca toate aceste rezultate au fost obtinute pentru N = 10 
(numarul tactelor necesare procesorului pentru un acces la memorie în caz de 
miss), acolo unde nu se precizeaza altfel. 

În figura 5.2, comparatia între cache-urile unificate si respectiv cele separate 


se realizeaza în conditiile FR = 8, IR = 4, IBS = 32 si capacitate cache de 64 


locatii. In acest caz, se prezina ratele medii de procesare (IRmed) obtinute pentru 
fiecare benchmark în parte. Astfel, ratele medii armonice cbtinute (HM), practic 
unanim utilizate în literatura de specialitate, au fost IRu = 0.48 instr./tact, respectiv 
IRS = 0.49 instr./tact, cvasiidentice. Se mentioneaza din nou ca acesti indicatori 
înglobeaza toate procesele importante implicate de aceste arhitecturi cache. De 
asemenea se precizeaza ca, în cazul arhitecturilor separate, capacitatile cache-urilor 
pe instructiuni si date sunt considerate identice (32, 32). În figurile 5.3, 5.4, se 
prezinta tot indicatorul IR mediu, comparativ pentru cele doua arhitecturi cache, 
dar considerând capacitatea acestora marita la 512 si respectiv la 2k locatii. În 
conformitate cu cele concluzionate în capitolul 4, acesti parametri FR, IR, IBS sunt 
deosebit de realisti si mai ales conduc la o eficienta ridicata a procesarii structurii 


analizate. 


FR=8, IR=4, IBS=32, cache=64 
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Figura 5.2. Performanta separate vs. unificate, pe cache-uri de capacitate 64 intrari 
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Figura 5.3. Performanta separate vs. unificate, pe cache-uri de capacitate 512 intrari 

În primul caz, s-au obtinut medii IRu = 0.99 si IRs = 0.97 (superioare cu cca. 
2 % unificatele!) iar în al doilea caz, IRu=1.20 si IRs = 1.52 (superioare cele 
separate). Se considera totusi acest al doilea caz caracterizat de un cache de 2k ca 
fiind relativ nerealist în sensul în care avantajeaza în mod artificial arhitecturile 
separate. Acest fapt se explica prin capacitatea exagerat de mare a acestui cache 
(2k) în raport cu caracteristicile benchmark-urilor utilizate (acestea apartin unui 
spatiu de instructiuni < 2k), marindu-se astfel artificios rata de hit în cache si 


anulându-se deci avantajul unificatelor pe acest plan. 


FR=8, IR=4, IBS=32, cache=2k 
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Figura 5.4. Performanta separate vs. unificate, pe cache-uri de capacitate 2k intrari 


Oricum, concluzia obtinuta pâna în acest moment prin simulare este ca, în 
conditii similare, cele doua arhitecturi de memorii cache implica performante 
cvasiidentice, fapt situat în deplina concordanta cu estimarile analitice realizate în 
capitolul 4. De remarcat ca parametrii alesi sunt deosebit de realisti. În conditii 
echitabile de performanta, cu parametrii FR, IBS, IR si algoritmi de procesare 
eficienti, arhitecturile unificate ofera performante practic identice cu cele separate. 
Aceasta concluzie arata iarasi în mod clar faptul ca arhitecturile unificate trebuiesc 
reconsiderate. În plus, dupa cum am mai aratat, constructia si implementarea lor 
este mai facila [Rya93, IBM93]. 

În figura 5.5 se prezinta performante relative la astfel de modele de 


procesoare neconventionale, deosebit de agresive în domeniul prefetch-ului. Astfel 


s-a ales FR = 16, parametru posibil de atins intr-un viitor apropiat prin tehnici de 
predictie de tip DBTB care permit la ora actuala rate realiste de fetch de 14 
instructiuni [Wal96] sau prin alte tehnici agresive, dintre cele prezentate in 
capitolul 3. În acest caz s-au obtinut performante medii IRs = 0.58 si IRu = 0.52, 
un avantaj de 11% pentru cele separate. Cresterea parametrului FR de la 8 la 16 a 
adus un câstig mediu de performanta de cca. 18%. O exceptie o constituie 
programul queens unde pentru FR = 8 rezulta IRs = 0.47 iar pentru FR = 16 rezulta 
IRs = 0.43, mai putin performant. Explicatia poate consta în numarul mare de 
branch-uri care se fac specifice acestui program si care determina aducerea multor 
instructiuni practic inutil, având în vedere rata ridicata de fetch (FR=16). Oricum, 
înca o dovada ca eficienta prefetchului este esentiala în obtinerea marii 
performante. 

În continuare, s-a dorit sa se cerceteze comportamentul arhitecturilor 
unificate/separate daca capacitatea cache se mareste de la 64 locatii (figura 5.5) la 
512 locatii (figura 5.6). În acest caz, se obtin performante medii IRs = 1.21 si IRu 
= 1.10 cu 108% respectiv 111% superioare fata de ratele obtinute în cazul 


precedent. 


FR=16, IR=4, IBS=64, cache=64 E separate 
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Figura 5.5. Performanta separate vs. unificate, pe un procesor cu prefetch agresiv (64 intrari cache) 


Rezultatele continute in aceste doua grafice (5.5, 5.6) pot fi considerate 
realiste având în vedere faptul ca spatiul de instructiuni al benchmark-urilor 
Stanford este practic limitat mult sub 2k. În aceste conditii capacitati cache 
cuprinse între 64 cuvinte si 512 cuvinte sunt posibile si realiste. În figura 5.7, 
numai pentru arhitecturi de tip Harvard, se prezinta în mod cantitativ influenta unor 
capacitati diferite ale memoriilor cache asupra performantei. Pentru capacitati de 
64, 512 si 2k locatii, se obtin performante medii respectiv de 0.49, 0.97, 1.52 
instructiuni / tact. Cresterile de performanta medii sunt semnificative si anume de 


97% respectiv de 56% de la un nivel al capacitatii cache la altul. 


FR=16, IR=4, IBS=64, cache=512 E separate 
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Figura 5.6. Performanta separate vs. unificate, pe un procesor cu prefetch agresiv (512 intrari cache) 
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Figura 5.7. Performanta arhitecturilor Harvard functie de capacitatea cache-urilor 


În aceleasi conditii, însa în cazul unor arhitecturi non-Harvard, se obtin 
performante medii IRu = 0.48, IRu = 0.99 si IRu = 1.20 (figura 5.8). Asadar în 
acest caz se constata din nou cresteri semnificative de 106% si respectiv 21%. 
Având în vedere ca un cache de capacitate 2k intrari este nerealist de mare datorita 
caracteristicilor programelor Stanford si tinând cont de rezultatele anterioare, 
devine clar ca marirea capacitatii cache în limite rezonabile avantajeaza unificatele. 
Acest lucru este explicabil pe baza cresterii ratei de hit datorata maririi capacitatii 


cache. 


FR=8, IR=4, IBS=32 m cache 64 
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Figura 5.8. Performanta arhitecturilor unificate functie de capacitatea cache-urilor 


În cele doua figuri urmatoare (figura 5.9 si figura 5.10), se prezinta influenta 
maririi capacitatii bufferului de prefetch asupra indicatorilor de performanta 


globali IRs si IRu. 


FR=4, IR=2, cache=512 
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Figura 5.9. Performanta arhitecturilor separate functie de capacitatea bufferului de prefetch 


În cazul Harvard, o crestere a lui IBS de la 8 la 64 de instructiuni, determina 
o crestere medie a indicatorului IRs de la 0.64 la 0.66, nesemnificativa. În celalalt 
caz, acelasi fapt determina o crestere medie a lui IRu de la 0.73 la 0.74, de 
asemenea nesemnificativa. În ambele cazuri rezulta ca IBSoptim = 8, altfel spus 
IBSoptim = 2FR, rezultat aflat iarasi în deplina concordanta cu cele obtinute pe 
baza pur teoretica în capitolul 4. Acest lucru este demonstrat si de faptul ca pentru 
FR = 8, IR = 4, cache = 512 locatii, s-a obtinut un IBSoptim = 16 (marirea acestuia 


determina o crestere asimptotica a performantei), adica tot 2*FR. 


FR=4, IR=2, cache=512 BIBS =8 
E IBS = 64 
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Figura 5.10. Performanta arhitecturilor unificate functie de capacitatea bufferului de prefetch 


În continuare (figura 5.11) se prezinta influenta capacitatii asupra ratei de 
miss în cache-ul de date. S-a considerat ca I-Cache si D-Cache au capacitati egale. 
Pentru capacitati de 64, 512 si 4k intrari, s-au obtinut procentaje de miss de 50%, 
24% si 0.3% respectiv. Devine acum clar ca pentru capacitati realiste ale D-Cache, 
cuprinse între 64 si 512 în acest caz, performanta si gradul de utilizare ale acestora 
sunt relativ scazute. Acest rezultat este în deplina concordanta cu cele obtinute prin 
intermediul altor cercetari, putine dar oarecum similare [Hen96]. În figura 5.12 se 
prezinta efectul pe care îl are asupra performantei dezechilibrarea capacitatii cache- 
urilor în conditii de capacitate totala constanta, în arhitecturile de tip Harvard. 
Astfel pentru capacitati egale de 512 locatii se obtine IRs = 1.27 iar pentru I-Cache 


= 128 si D-Cache = 996 se obtine IRs = 1.10. Asadar o dezechilibrare a capacitatii 


în favoarea cache-ului de date conduce la o degradare a performantei cu cca. 15%, 


fapt confirmat de altfel si prin alte experimente realizate cu acest simulator. 


B cache = 64 
B cache = 512 
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Figura 5.11. Influenta capacitatii D-Cache asupra ratei de miss 
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Figura 5.12. Dezechilibrarea capacitatii cache-urilor 


Pe baza a numeroase simulari a rezultat clar ca nu este recomandabila nici 
dezechilibrarea capacitatii în favoarea D-Cache in scopul optimizarii de 
performanta, cel putin pentru programele Stanford si pentru capacitati rezonabile, 
limitate tehnologic, ale cache-urilor. În opinia autorului capacitatile egale implica 
performante optime. Desigur ca acest lucru este valabil numai în conditii relativ 
restrictive impuse capacitatii totale a cache-ului (v. în continuare). În aceleasi 
conditii cu cele din figura 5.12 dar considerând I-Cache = 768 si D-Cache = 256 s- 
a obtinut IRsmediu = 0.97, nesatisfacator. 

În continuare se doreste analiza capacitatilor optime ale I-Cache respectiv D- 
Cache în conditii nerestrictive ale capacitatii totale. Astfel în figura 5.13 se prezinta 
variatia performantei IRs, considerând un cache de date practic nelimitat 
(cvasiideal) si variind capacitatea Cache. Astfel, pentru un Cache de 64 locatii, 
se obtine performanta medie armonica IRs= 1.28 iar pentru I-Cache de 256 locatii, 


IRs= 2.36. 


FR=8, IR=4, IBS=16, D-CACHE=16k E I-CACHE = 64 
B I-CACHE = 256 
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Figura 5.13. Optimizarea capacitatii I-Cache în conditii D-Cache practic infinit 


Asadar se constata o crestere a performantei în acest caz cu cca. 84%. O 
capacitate a I-Cache mai mare de 256 locatii, practic nu mai mareste performanta 
ceea ce arata ca aceasta capacitate este cea optima din punct de vedere al 
performantei, în conditii mai putin restrictive ale capacitatii D-Cache. În figura 
5.14 se prezinta rezultatele problemei reciproce, si anume de a determina 
capacitatea optima a D-Cache în conditii nerestrictive ale capacitatii -Cache (16k 
intrari aici deci practic infinita). În acest caz, rezultatele optime IRs se obtin pentru 
un D-Cache de 4k dupa cum se poate observa. Mai precis s-au obtinut pentru 
capacitati D-Cache de 256, 1k, 4k, performante medii de 0.95, 1.48 si 2.06 
respectiv. O marire a capacitatii memoriei cache de date peste 4k, termina 


cresteri asimptotice ale performantei. 


Concluzia este una interesanta, întrucât a rezultat ca in conditii mai putin 
restrictive ale capacitatii totale a memoriei cache, I-Cache optim este de 256 locatii 
iar D-Cache optim de 4k locatii !. Aceasta concluzie îndreptateste si justifica 
alegerea lui D-Cache mult mai mare decat cea a lui I-Cache in anumite procesoare 
RISC superscalare (IBM RS/6000, 8k ECache, 64k D-Cache), în conditii practic 
nerestrictive ale capacitatii totale a cache-ului, deci in care bugetul de tranzistori 
integrati pentru cache-uri a fost unul marit. In schimb, concluzia aceasta contrazice 
alegeri inverse, întâlnite si ele in anumite realizari comerciale (AMD KS, 
SuperSPARC). Evident ca rezultatele de aici se bazeaza pe reprezentativitatea 


deosebita a programelor Stanford utilizate pentru aplicatiile de uz general. 


FR=8, IR=4, IBS=16, I-CACHE=16k a D-CACHE=256 
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Figura 5.14. Optimizarea capacitatii D-Cache în conditii I-Cache practic infinit 


În figura 5.15 se prezinta rata medie globala de miss pentru diferite cache-uri 
unificate implementate. Astfel, pentru capacitati de 64, 512, 4k s-au obtinut rate de 
miss medii de 40%, 12%, 2.3% respectiv, ceea ce demonstreaza clar ca gradul de 


utilizare al cache-urilor unificate este superior (a se compara cu figura 5.11). 
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Figura 5.15. Rata de miss pentru arhitecturi unificate avand capacitati diferite 


În figura urmatoare (figura 5.16) se prezinta indicatorul IBE obtinut pentru 
arhitecturi unificate pentru parametrii FR = 4 si FR = 8. In medie s-a obtinut IBE = 
61% respectiv IBE = 27% rezultând deci prin aceasta crestere posibila a 
parametrului FR o imbunatatire semnificativa a lui IBE. Rezultatul acesta obtinut 
prin simulare se gaseste iarasi intr-o foarte buna concordanta cu cele obtinute in 


capitolul 4 pe baza pur analitica (vezi figura 4.19 si figura 4.20). IBE mediu in 


conditii similare într-o arhitectura Harvard simulata, sa obtinut de cca 7%, net 


superior datorita faptului ca aici nu exista coliziuni. 
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Figura 5.16. Influenta FR asupra IBE la arhitecturile Princeton 
În figura urmatoare (figura5.17), se prezinta procentajul din timpul total al 
procesorului cu cache-uri unificate, cât acesta declanseaza cicluri de aducere a 
instructiunilor. Rezultatele se prezinta aici comparativ pentru 2 modele: unul "slab" 
caracterizat prin FR = 4, IBS = 8, IR = 4, capacitate cache unificat = 64 intrari si 
altul "tare", adica caracterizat de parametrii FR = 8, IBS = 32, IR = 4, capacitate 


cache = 16k. 
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Figura 5.17. Fractiunea de timp cât CPU executa cicli de aducere a instructiunilor pe 2 modele 


S-a obtinut pentru cel "slab" 12.3% în medie, iar pentru cel "tare" 50% în 
medie. Asadar, în cazul modelului "tare" prefetch-ul este performant datorita 
optimalitatii parametrilor arhitecturii, care diminueaza din procesele de coliziune si 
miss-urile în cache. În acest caz aducerea de instructiuni se realizeaza în mod 
performant. Urmatoarea analiza (figura 5.18) abordeaza problematica influentei 
latentei memoriei principale asupra performantei arhitecturilor unificate de cache. 
Se prezinta rezultatele obtinute pentru o latenta N de 10 tacte, respectiv 20 de tacte. 
IRu medii obtinute sunt de 1.29 respectiv 0.86 instr./tact. Asadar se constata o 
reducere a performantei cu cca 50% în acest caz determinata de dublarea latentei 


memoriei principale. Rezulta deci o influenta semnificativa a latentei memoriei 


principale in cadrul acestei arhitecturi, favorizata si de procesele de coliziune 


implicate. 


FR=8, IR=4, IBS=16, CACHE=1k 
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Figura 5.18. Influenta latentei memoriei principale asupra performantelor unui CPU superscalar cu 
cache-uri unificate 


O solutie citata in literatura [Hen96], propusa pentru prima data de catre 
cercetatorul Norman Jouppi cu scopul reducerii ratei de miss si care nu afecteaza 
frecventa de tact a CPU, consta in adaugarea unui cache de dimensiune redusa, in 
general total asociativ, intre memoria cache propriu-zisa (cu mapare directa) si 
magistrala de legatura cu memoria principala. Aceasta memorie cache este 
cunoscuta sub numele de "victim cache" (VC) si va contine doar acele blocuri 
eliminate din memoria cache propriu-zisa in caz de miss. In caz de miss in cache, 


se cauta in VC daca blocul dorit poate fi localizat aici. În caz ca da, acest bloc va fi 


interschimbat cu blocul din cache care ar urma sa fie evacuat. Altfel spus, orice 
bloc din cache care urmeaza sa fie evacuat in memoria principala, va fi inscris in 
acest VC. O sinteza a acestui concept cu acela de cache NRP prezentat succint in 
paragraful 4.4, ar putea fi benefica in contextul arhitecturilor cu paralelism redus, 
în opinia mea. În literatura se arata ca VC-uri de capacitate mica se pot cupla cu 
memorii cache mapate direct, de capacitate redusa, cu rezultate deosebit de 
eficiente. Se mentioneaza ca un VC poate reduce semnificativ din procesele de 
interferente in cache-urile cu mapare directa (blocuri diferite din memoria 
principala mapate în acelasi bloc in cache). Conceptul VC este implementat cu 
succes in microprocesorul comercial de mare performanta HP 7200 (Hewlett - 
Packard). 

În figura 5.19, se prezinta cresterile de performanta introduse de catre un VC 
asociativ cu 8 intrari, plasat într-o configuratie de procesor, având FR=8, IR=4, 
IBS=16 si capacitatea cache (unificat) de 256 intrari. S-a implementat o memorie 
cache cu mapare directa si algoritmi de evacuare de tip LRU (Least Recently Used) 
sau "pseudo-random". Sa obtinut o rata medie armonica de procesare de 0.82 
instr./tact fara VC, respectiv de 0.92 instr./tact cu VC, adica o crestere globala de 
cca. 12% datorata acestei mici memorii asociative, ceea ce este seminificativ si 
demonstreaza în mod clar viabilitatea solutiei. O cercetare care sar impune în 
continuare ar consta în compararea acestei solutii cu arhitecturi cache având 


diferite grade de asociativitate, desigur în conditii de complexitate echitabile. 


E cu victim cache 
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Figura 5.19. Influenta cache-ului de tip "victima" asupra ratei de procesare 

În [Sti94] se propune o îmbunatatire interesanta a conceptului de cache 
victima, prezentat si evaluat mai sus, printr-o asa numita memorie cache victima de 
tip selectiv (Selective Victim Cache - SVC). În cadrul acestei noi arhitecturi cache, 
blocurile aduse din nivelul superior de memorie pot fi stocate în memoria cache 
principala, cu mapare directa, sau în SVC, bazat pe probabilitatea de a fi utilizate 
în viitor. Astfel, blocurile care au o probabilitate de utilizare în viitor relativ 
scazuta, vor fi introduse in SVC, cele cu o probabilitate relativ ridicata, în memoria 
cache principala. Similar, în cazul unui miss în cache-ul principal coroborat cu un 
hit în SVC, se va aplica un asa numit algoritm de predictie, cu scopul de a 
determina daca este sau nu nevoie de o interschimbare a blocurilor conflictuale 


A 


(unul în cache-ul principal, celalalt in SVC). Evident, algoritmul de predictie 


impune determinarea probabilitatii de utilizare a blocului respectiv în "viitorul 
apropiat", pe o baza euristica rezultata din procesarea unei informatii de stare pe 2 
biti, dupa cum se va arata. 

Ca si cache-ul victima simplu (VC), SVC este o memorie de capacitate 
redusa, cu un grad sporit de asociativitate, interpusa între cache-ul principal cu 
mapare directa si nivelul superior de memorie. Memoria cache principala (MCP) si 
SVC-ul sunt baleiate în paralel la orice acces la memorie al procesorului. Latenta 
SVC este considerata - în baza articolului original [Sti94]- mai mare decât cea a 
MCP dar mai mica decât latenta nivelului superior de memorie. Acest lucru are 
sens în opinia mea, numai daca se considera o MCP adresata cu adrese virtuale 
(cache virtual, avantajos dar dificil de implementat) si o SVC adresata cu adrese 
fizice, fapt necesar având în vedere ca în general aceasta memorie este complet 
asociativa. În acest sens se precizeaza ca o memorie asociativa este mai dificil sa 
fie adresata cu adrese virtuale decât una cu mapare directa, întrucât problema 
aliasurilor de memorie (doua adrese virtuale distincte mapate pe aceeasi adresa 
fizica) este mai dificil de rezolvat în acest caz. Oricum, în aceasta abordare s-ar 
putea într-adevar considera ca latenta SVC este mai mare decât cea a MCP, având 
în vedere procesul aditional de translatare a adresei virtuale în adresa fizica prin 
accesarea unor tabele de translatare din memoria principala sau a unor TLB-uri 
(Translation Lookaside Buffers) rezidente "on-chip". Din pacate articolul lui 


Stiliadis si Varma nu realizeaza aceste aspecte relativ subtile. Memoria SVC se 


asociaza cu memorii cache principale mapate direct, în vederea îmbunatatirii 
performantelor acestora din urma. Reamintim ca aceste memorii cache cu mapare 
directa sunt cele mai simple si mai usor de integrat în circuit, având timpul de 
acces cel mai redus dar si o rata de miss mai ridicata decât la tipurile asociative, 
datorita în principal interferentelor blocurilor conflictuale. Ele se preteaza cel mai 
bine la procesarea pipeline care impune actualmente (anul 1998) timpi de acces 
mai mici de 5 ns (DEC Alpha, MIPS 4000, MicroSparc). În plus, cu astfel de 
memorii cache, data (instructiunea) poate fi adusa de catre procesor înainte ca 
verificarea tag-urilor sa se fi încheiat, ceea ce la cele asociative este imposibil 


întrucât procesul de cautare al datei în cache se face chiar dupa tag. 


Figura 5.20. Locul SVC în cadrul interfetei CPU - memorie principala 


Arhitectura SVC încearca deci sa izoleze doua blocuri conflictuale prin 


memorarea unuia in MCP si a celuilalt în SVC. În MCP se va memora blocul 


predictionat ca fiind mai utilizat in viitorul apropiat. Pe baza algoritmului de 
predictie a blocului care va fi mai utilizat, se va reduce numarul de interschimbari 
de blocuri între MCP si SVC, comparativ cu arhitectura "cache victima" originala, 
propusa de N. Jouppi de la compania DEC, în 1990. Aceasta reducere a 
interschimbarilor va avea consecinte favorabile asupra timpului global de acces la 
MCP respectiv SVC. 

Dupa cum se poate observa in figura anterioara, MCP contine în plus un bloc 
aditional numit bloc tranzitoriu (BT). În cazul unui hit in SVC si daca algoritmul 
de predictie nu decide interschimbare de blocuri, atunci blocul din SVC este copiat 
în BT, acesta servind ca buffer astfel încât accesele secventiale urmatoare în cadrul 
blocului sa poata fi satisfacute prin accesarea acestui BT. În mod similar, în cazul 
unui miss în SVC, daca algoritmul de predictie impune încarcarea blocului în SVC, 
acesta va fi de asemenea încarcat si în BT, accesele realizându-se ca în figura 


urmatoare (5.21). 
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Figura 5.21. Accesarea blocului tranzitoriu din SVC 


In cazul accesului normal, la un nou bloc, se disting trei cazuri: 


1. Hit in MCP. Se acceseaza MCP, în plus se actualizeaza bitii de predictie. 

2. Miss în MCP si hit în SVC. Daca algoritmul de predictie constata ca blocul 
din SVC detine un potential de accesabilitate mai ridicat decât blocul 
corespunzator din MCP, atunci se va executa o interschimbare între blocurile 
conflictuale din MCP respectiv SVC. În caz contrar, blocul din SVC se copiaza în 
BT si automatul intra în starea "acces BT". 

3. Miss in MCP si miss in SVC. În acest caz se va accesa nivelul superior de 
memorie. Daca blocul adus detine un potential de accesabilitate mai ridicat decât 
blocul conflictual din MCP, ultimul este stocat în SVC iar noul bloc adus va fi 
înscris în MCP; în caz contrar, noul bloc se înscrie în SVC si în BT, iar automatul 
intra în starea "acces BT". 

Deosebirile fata de un VC simplu constau în cazurile 2 si 3 unde în cazul de 
cache victima clasic, interschimbarile se faceau întotdeauna, pe când aici, acestea 
se fac într-un mod selectiv, inteligent. 

Algoritmul de predictie 

Se aplica ori de câte ori accesul curent determina un conflict cu un bloc din 
MCP (miss). Scopul algoritmului este acela de a determina care bloc dintre cele 
doua blocuri conflictuale este mai probabil de a fi accesat în viitor. Blocul 
respectiv va fi introdus în MCP iar celalalt in SVC. Algoritmul utilizeaza 2 biti de 
stare asociati cu fiecare bloc din cache, numiti bit de hit (HB) si respectiv "sticky" 


bit (SB). Bitul HB este asociat fiecarui bloc din nivelul 1 de cache (L1). Daca este 


']' arata ca a aparut cel putin un hit pe bloc, pe când acesta a fost ultima data în 
nivelul 1 de cache. Bitul SB este si el asociat fiecarui bloc din nivelul 1. Cand un 
bloc e adus in cache, bitul SB corespunzator este setat, orice hit ulterior 
mentinându-l setat. La o referire la un bloc conflictual celui din MCP, daca 
algoritmul de predictie nu le interschimba, bitul SB aferent blocului din MCP se 
pune pe '0'. La un nou conflict, blocul din MCP cu SB=0 este evacuat. Asadar daca 
un bloc din cache are bitul SB=1, rezulta ca el nu a fost in conflict cu nici un alt 
bloc, pe timpul cat a fost stocat in MCP. 

În mod normal, într-o implementare perfecta a conceptului arhitectural de 
SVC, bitii de hit ar trebui stocati în memoria principala, ceea ce ar putea crea 
anumite probleme legate de complexitate si costuri. De aceea în [Sti94] se propun 
anumite implementari "aproximative", mai realiste, în sensul reducerii necesitatilor 
de memorare pentru bitii de hit. Astfel de exemplu, se propune implementarea unui 
"hit array", ca parte a MCP si care permite printr-un mecanism tip "mapare 
directa", mai multor biti HB corespunzatori blocurilor memoriei principale sa fie 
mapati in aceeasi locatie a acestui "hit array". Cu alte cuvinte se realizeaza o 
mapare a bitilor de hit teoretic rezidenti în memoria principala, într-un cache 
dedicat, cu rezultate obtinute prin simulari, foarte apropiate de cele generate printr- 
o implementare ideah. În [Vin98c], autorul acestei monografii a aratat ca o mai 
mare gradualitate a lui "hit" si "sticky", prin implementarea acestora ca vectori 


binari cu modificarea corespunzatoare a algoritmului de predictie, poate conduce la 


performante superioare ale conceptului de SVC. Astfel s-a aratat ca 2 biti de "hit" 
respectiv "sticky", conduc la rezultate optimale în conditii fezabile ale 
implementarii hardware. 

Notând acum cu A un bloc situat în MCP aflat în conflict cu un bloc notat B 
si situat in SVC sau în nivelul 2 de memorie, algoritmul de predictie este prezentat 
în continuare. 

Cazul 0: Acces la blocul B, hit in cache 

Sticky[B] — 1; hit{B] = 1 
Cazul 1: Acces la blocul B, hit in selective victim cache 
A este blocul conflictual din cache-ul principal 
if sticky[A] = O then 
interchange A and B 
Il sticky[B] — 1; hit[B] — 1 (hit[B] 3 0, modificarea mea!) 


copy B to transitory block 


else 
if hit[B] = O then 
1.2 sticky[A] — 0; 
copy B to transitory block 
else 
1.3 interchange A and B 


sticky[B] — 1; hit[B] 7 0; 


end if 
end if 
Cazul 2: Acces la blocul B, miss atât in cache cât si în SVC 
A este blocul conflictual din cache-ul principal 
if sticky[A] = 0 then 
move A to victim cache 
transfer B to main cache 
Zed sticky[B] — 1; hit[B] — 1 (hit{B] — 0) 
else 
if hit[B]=0 then 
transfer B to victim cache 
copy B to transitory block 


sticky[A] = 0 


else 
move A to victim cache 
transfer B to main cache 
sticky[B] => 1; hit[B] — 0 
end if 


endif 


Acum devine mai clar rolul tamponului BT, în acest sens considerându-se de 


exemplu o secventa de instructiuni de tipul (A™B)", unde A si B sunt doua blocuri 


conflictuale în cache. Notatia (A™B)®, semnifica 2 bucle de program imbricate, 
prima (A) facându-se de m ori iar bucla "mare" de n ori. În acest caz, pentru a nu 
mai fi necesare interschimbari, un bloc se acceseaza din MCP iar celalalt din BT. 

Simularile au utilizat 3 metrici de evaluare a performantelor: rata de miss 
(locala), timpul mediu de acces (globala) si numarul de interschimbari de blocuri 
între MCP respectiv SVC. Concluziile au aratat îmbunatatiri semnificative ale 
acestor 3 metrici fata de cazul VC simplu. Astfel, de exemplu, numarul de 
interschimbari a scazut cu 50% pe cache-ul de instructiuni. Pe cache-ul de date, 
rezultatele au fost mai slabe (benchmark-urile SPECint '92) datorita structurilor de 
date neregulate. Îmbunatatiri ale conceptului de SVC (vezi de ex. modificarea 
initializarii bitului de hit din cadrul algoritmului, benefica, reducând numarul de 
interschimbari între MCP si SVC fata de algoritmul original cu cca. 3%) precum si 
detalii cantitative ale unor cercetari efectuate de catre autorul prezentei lucrari, pot 
fi gasite în [Vin98c, Arm98]. 

În continuare se va prezenta în aceeasi maniera cantitativa, fenomenul de 
interferenta instructiuni-date, care apare în memoriile cache unificate. Înteleg 
printr-o asemenea interferenta, procesul de evacuare a unei instructiuni din cache 
de catre o data si invers, cu efecte defavorabile asupra performantei. Este evident 
ca acest proces nu va aparea în cazul memoriilor cache separate. Asadar, rata de 
interferenta instructiuni-date reprezinta procentajul din totalul actualizarilor într-un 


cache unificat care implica procese de interferenta între instructiuni si date. Se 


precizeaza ca urmatoarele 6 grafice, care au in vedere diverse procese legate de 
arhitecturile cache unificate (Princeton), au la baza implementarea unui mecanism 
realist de lansare in executie a instructiunilor din bufferul de prefetch, de tip In 
Order si care tine cont de hazardurile RAW intre instructiunile din acest buffer. 
Practic, primele IRmax instructiuni din bufferul de prefetch constituie fereastra 
curenta de executie. Din aceasta fereastra curenta, se lanseaza în executie simultan 
N instructiuni independente RAW, N<IRmax, în paralel cu aducerea urmatoarelor 
FR instructiuni din cache. Apoi, tinând cont de eventualele instructiuni netrimise în 
executie din cadrul ferestrei curente, se construieste noua fereastra de executie, 
formata iarasi din primele IRmax instructiuni din bufferul de prefetch, dupa care 
procesele de executie si fetch se repeta întocmai. Nu s-a tinut cont în simulare de 
dependentele tip WAR sau WAW. 

Revenind la analiza cantitativa, figura 5.22 prezinta evolutia ratei de 
interferenta instructiuni-date pentru capacitati ale cache-ului de 64, 128 si 1024 
intrari. S-au obtinut rate medii ale interferentelor de 24.7%, 14.4% si respectiv 
2.4%. De precizat ca un cache de 2048 intrari, cam mare însa având în vedere 
caracteristicile benchmark-urilor Stanford HSA, elimina practic total aceste 
interferente (0.007%!). Acest fenomen poate deci constitui un dezavantaj 
semnificativ pentru arhitecturile Princeton de capacitate redusa. De mentionat ca s- 
au considerat cache-uri biport pe date, latenta memoriei principale de 10 tacte CPU 


si un procesor având FR=4, IBS=8, IR=4. 


@ cache=64 


© 
= 
[= 
D 
= 
o 
2 
- 
o 
2 
= 
© 
s 
© 
ac 


ol , J 
bubble sort perm  puzz queen matr tree tow 


Figura 5.22. Rata de interferenta instructiuni - date la cache-urile unificate 


În continuare, acolo unde nu se fac alte precizari, rezultatele simularilor se 
prezinta pentru un cache unificat biport de capacitate 1024 de intrari si un procesor 
având IBS=16, FR=8, IR=4. În figura 5.23, se prezinta influenta numarului de 
seturi de registri fizici asupra performantelor, considerând un cache biport pe date. 
Pentru 2, 3 si 4 seturi s-au obtinut rate de procesare de 1.03, 1.09 si 1.11 instr./tact, 
adica cresteri relative de 5.8% respectiv 7.8%, relativ mici. Pe benchmark-ul 
"matrix" de exemplu, cea mai buna performanta se obtine pentru doar doua seturi 
fizice de registri generali, @ea ce pare paradoxal. Aspectul este însa explicabil 
având in vedere arhitectura unificata a cache-urilor implicând coliziuni si pattern- 
urile defavorabile care pot sa apara, relativ la distributia instructiunilor LOAD în 


faza de lansare în executie, în sensul unei medii mai apropiata de o singura astfel 


de instructiune in cadrul ferestrei curente de executie, conducând deci la 


serializarea executiei acestor instructiuni consumatoare de timp. 


cache biport pe date 
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Figura 5.23. Influenta numarului de seturi de registri asupra performantei arhitecturilor Princeton 
(cache biport) 


În figura 5.24 se prezinta acelasi aspect doar ca, de aceasta data, pentru un 


cache unificat de tip uniport pe date. 


cache uniport pe date 
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Figura 5.24. Influenta numarului de seturi de registri asupra performantei arhitecturilor Princeton 
(cache uniport) 


Si aici cresterea relativa de performanta intre doua seturi fizice si 4 seturi 
fizice este de doar 5.1%, mai redusa chiar decat in cazul anterior. Asadar, marirea 
setului de registri nu conduce la o crestere spectaculoasa a performantei, aspect 
datorat probabil si gradului limitat de paralelism (executie In Order pe programe 
neoptimizate), determinat de catre dependentele RAW intre instructiunile din 
buffer. Figura 5.25 prezinta ratele de procesare obtinute pentru un cache unificat 
uniport, respectiv biport pe date. Rezultatele obtinute sunt previzibile, obtinandu-se 
medii armonice ale ratelor de procesare de 1.01, respectiv 1.11 instr./tact, adica o 
crestere relativa de 10% în favoarea celor biport. 

În continuare s-a abordat problema cache-urilor unificate de tip "non- 


blocking", caracterizate de faptul ca CPU poate continua extragerea instructiunilor 


din cache-ul de instructiuni in timp ce asteapta furnizarea datei lipsa din memoria 
principala (miss pe date). Conceptul este perfect implementabil si pe arhitecturile 


separate de memorii cache. 
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Figura 5.25. Comparatie între performanta unui CPU având cache uniport respectiv biport 

Desigur ca este necesar ca, dupa miss-ul pe date, sa existe hit pe prefetch, 
altfel performanta nu se îmbunatateste. Pâna în acest moment, toate simularile pe 
arhitecturile unificate au presupus inhibarea prefetch-ului imediat dupa constatarea 
unui miss pe o instructiune LOAD. Facilitatea "non-blocking" presupune in mod 
evident complicarea arhitecturii procesorului si a memoriei cache. Figura 5.26 
arata rezultatele obtinute prin simularea unei astfel de scheme în care prefetch-ul 
continua chiar dupa un miss pe date. Cu aceasta facilitate s-a obtinut o rata medie 


de procesare de 1.24 instr./tact, iar fara, o rata de 1.09 instr./tact. Cresterea medie 


de performanta este de cca. 14%, deci deosebit de semnificativa, aratând forta 
acestui concept arhitectural. Acest concept agresiv de cache-uri "non- blocking" 
este implementat în microprocesoarele comerciale de mare performanta DEC 


Alpha 21064 si MIPS R 10000. 


@ cache non-block 
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Figura 5.26. Influenta unui cache tip "non-blocking" asupra performantei unui procesor superscalar 


Mai departe, s-a dorit analiza cantitativa, realizata în premiera, a 
implementarii instructiunilor combinate ("combining", "collapsing", [Vas93]), 
asupra unei arhitecturi superscalare cu memorii cache unificate. Aceste instructiuni 
provin din sinteza, realizata prin mijloace hardware de tip colapsare "run-time" sau 
software (static, prin scheduler), a doua instructiuni dependente RAW într-una 
singura mai complexa. Nu este absolut necesar ca cele doua instructiuni combinate 


sa fie consecutive, ci doar succesive în program. Este însa necesar ca unitatile 


functionale din cadrul CPU sa permita executia acestor instructiuni combinate, care 
pot avea 3 operanzi sursa in loc de doi. Ideea se bazeaza pe un articol al lui S. 
Vassiliadis [Vas93], in care se arata ca este posibila implementarea unor unitati 
aritmetice si logice cu trei operanzi in loc de doi, practic fara consecinte 
defavorabile asupra latentei acestora. În acest studiu, am considerat posibila doar 
combinarea a doua instructiuni HSA dependente de tip aritmetico-logic sau a unei 
instructiuni aritmetico-logice urmata de o instructiune LOAD / STORE. De 
asemenea am considerat ca operatia de combinare cade în sarcina compilatorului 
(scheduler-lui), realizându-se deci în nod static. Rezulta clar ca în urma acestui 
proces se va reduce numarul de instructiuni din cadrul programului. În figura 5.27 
se prezinta comparativ performantele obtinute fara si respectiv cu utilizarea 
instructiunilor combinate. Sa obtinut o performanta medie de 1.17 instr./tact fata 
de 1.11 instr./tact fara instructiuni combinate, asadar o crestere a performantei de 
cca 5.4%, ceea ce reprezinta surprinzator de putin. Mai mult, pe benchmark-ul 
"bubble", performanta fara instructiuni combinate fata de cea cu instructiuni 
combinate, scade de la 2.24 la 1.86 instr./tact, ceea ce aparent este mai greu de 
explicat. Explicatia de principiu ar putea consta totusi în faptul ca prin combinare, 
procentajul instructiunilor LOAD / STORE creste în cadrul programului, prin 
urmare gradul de coliziune implicat de aceste instructiuni creste si el inhibând 
procesul de prefetch, bufferul de prefetch devine mai ineficient si deci performanta 


globala scade. Oricum, este interesanta aceasta influenta a instructiunilor 


combinate pe arhitecturile Princeton si concluzia ar fi ca beneficiul implicat este 
prea mic pentru a se impune. Concluzia este interesanta intrucat cercetari realizate 
pe arhitecturi Harvard arata in mod clar ca instructiunile combinate duc la o 
crestere semnificativa a performantei. În capitolul 7 al prezentei lucrari se 
demonstreaza clar acest fapt, bazat pe simularea unui model idealizat de procesor 
Harvard. O cercetare recenta de amploare asupra influentei instructiunilor 
combinate asupra performantei arhitecturilor superscalare, la care a contribuit si 


autorul acestei lucrari, poate fi gasita in [Pot98]. 
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Figura 5.27. Influenta instructiunilor combinate asupra unei arhitecturi superscalare tip Princeton 


Din cele prezentate pâna acum, apare urmatoarea dilema: cum este mai bine, 
sa realizam un cache mai rapid care sa tina pasul cu viteza procesorului, sau unul 


mai mare, care sa compenseze în capacitate diferenta de viteza între CPU si 


memoria centrala ? Un posibil raspuns la aceasta problema îl constituie utilizarea 
unui cache secundar, interpus deci intre memoria cache propriu-zisa si memoria 
centrala. Întrucât intreaga informatie ce se afla in primul nivel de cache, se va afla 
probabil si in al doilea nivel (incluziune multinivel), rezulta ca acesta ar trebui sa 
fie semnificativ mai mare decat primul. Totusi, in realitate nu orice informatie din 
primul nivel se va afla în mod necesar si în al doilea, aceasta depinzând de 
protocolul de scriere implementat pe aceasta ierarhie de memorii ("write through”, 
"write back") [Hen96, Sto93, Sta96]. Cu alte cuvinte, actualizarile în cadrul cache- 
ului secundar se pot face de exemplu doar în cazul unor citiri cu miss din acest 
cache sau în cazul unor evacuari din cel principal. Din acest motiv, nu se poate 
afirma cu certitudine ca primul nivel este inclus total în cel de-al doilea. Daca se 
utilizeaza tehnica "write back" pe nivelul 2, trebuie folosita tehnica "write through" 
pe nivelul 1, pentru ca nivelul 2 de cache sa functioneze ca un tampon pentru 
scrierile repetate. În general în arhitecturile MEM; memoriile cache primare sunt 
împartite pe instructiuni si date fiind implementate "on - chip", în timp ce cache-ul 
secundar este unificat, fiind implementat deseori în exteriorul procesorului. Având 
în vedere faptul ca numarul de pini reprezinta o conditie deosebit de restrictiva, 
este clar de ce cache-ul secundar este de tip unificat (microprocesoarele DEC 
Alpha 21164, Pentium, Pentium Pro, etc.). 

O metrica locala de evaluare a performantei unei memorii cache o reprezinta 


rata de miss locala (RL) definita ca fiind raportul între numarul de accese cu miss 


in cache si respectiv numarul total de accese in cache. Într-un sistem cu doua 
nivele de cache, se poate defini o asa-zisa rata de miss globala (RG) dupa relatia: 

RG=RL1*RL2 (5.2) 

Desigur ca latenta memoriei cache secundare este mai mare decat a celei 
primare, dar net mai mica decât latenta memoriei centrale. De observat ca o citire 
cu miss din sistemul ierarhizat de memorii cache determina serializarea latentelor 
memoriei centrale si respectiv a memoriilor cache secundare si primare. Aceasta, 
întrucât dupa citirea din memoria centrala, apare necesitatea actualizarii datei sau 
instructiunii citite în sistemul de cache-uri, fapt care implica adaugarea latentei 
acestora la aceea a memoriei principale. Din acest motiv, nu este exclus ca în 
anumite conditii total defavorabile, performanta unui sistem fara cache secundar sa 
fie superioara aceleia a unui sistem cu memorie cache pe nivelul 2 ! 

Figura 5.28 prezinta în mod comparativ performanta unui sistem cu si fara 
cache secundar. S-au considerat memorii cache separate (I-Cache=64 intrari, D- 
Cache=128, Cache secundar=5 12), latenta memoriei cache secundare de 3 tacte, a 
celei primare de un tact si latenta memoriei centrale de 15 tacte. De asemenea s-a 
ales FR=IR=4, IBS=8. S-au obtinut rate medii armonice de procesare de 0.38 
respectiv 0.53 instr./tact, asadar o crestere relativa de performanta datorata cache- 
ului secundar de cca. 39%, ceea ce este absolut remarcabil. Figura 5.29 prezinta 
rezultatele obtinute în conditii similare, cu deosebirea ca de aceasta data sau 


considerat: I-Cache=64, D-Cache=5 12, CACHE secundar=2K intrari. 


B® secundary cache 
EI non secundary cache 


bubble matr perm  puzz queen sort tow tree HM 


Figura 5.28. Influenta cache-ului secundar asupra IR într-un CPU superscalar Harvard (I-Cache=64, 
D-cache=128, Nivel 2= 512 intrari) 
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Figura 5.29. Influenta cache-ului secundar asupra IR într-un CPU superscalar Harvard (I-Cache=64, 
D-cache=5 12, Nivel 2= 2k intrari) 


În acest caz, sau obtinut rate medii de procesare de 0.53 respectiv 0.87 
instr./tact, deci o crestere de cca. 64% datorata cache-ului secundar. O explicatie 
clara a beneficiului de performanta introdus de nivelul 2 de cache în acest ultim 
caz, este prezentata în figura 5.30 care prezinta ratele de miss locale pe cele doua 
nivele (MRLI, MRL2) precum si rata de miss globala RG(I-Cache=64, D- 
Cache=512, Cache secundar=2K). S-au obtinut medii aritmetice astfel: 
MRL1=17.8%, MRL2=24.2% si MRG=4.4%. Asadar, s-a obtinut o rata de hit 
globala în nivelele de cache de cca. 96% fata de 82% fara cache-ul secundar. Cu 
exceptia programului "puzzle", cele doua nivele de cache se compenseaza reciproc 
într-un mod exemplar. De remarcat ca MRL2 reprezinta o metrica dicienta in 
aprecierea utilitatii unei memorii cache secundare. Pot exista anumite configuratii 
hardware software în care eficienta acestor memorii secundare sa fie practic nula. 
Astfel, de exemplu, în cadrul analizat aici, pentru I-Cache=128 intrari, D- 
Cache=1K intrari si Cache secundar=2K intrari, pe programele "bubble" si 


"permute", practic toate accesele se fac în nivelul primar de cache. 
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Figura 5.30. Ratele de miss locale si globale pt. un sistem de cache-uri pe 2 nivele 


Interesant, pe baza masuratorilor efectuate, fenomenul de interferenta 
instructiuni - date este practic neglijabil pe al doilea nivel de memorii cache, în 
toate experientele efectuate. În figura 5.31 se prezinta variatia performantei globale 
considerând I-Cache=128, D-Cache=128, pentru 3 capacitati distincte ale 
memoriei cache secundare (512, 1024, 2048). S-au obtinut rate medii armonice ale 
ratelor de procesare de 0.58, 0.68 si 0.79 instr./tact, deci cresteri de performanta de 


cca. 17% de la o capacitate la alta, ceea ce este semnificativ. 
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Figura 5.31. Influeta capacitatii nivelului 2 de cache asupra performantei unui CPU superscalar 
Harvard 


În figura 5.32 se prezinta influenta micsorarii latentelor la nivelele de 
memorie asupra performantei. Evaluarea se prezinta pe o configuratie având 


FR=IRmax=4, IBS=8, I-Cache=64, D-Cache=512, CACHE secundar =2K. 
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Figura 5.32. Influenta latentelor nivelelor de memorie asupra performantei 


S-au considerat in primul caz latente de 3 tacte procesor pe cache-ul secundar 
si 15 tacte pe memoria centrala respectiv in al doilea caz de 2 tacte si 10 tacte. S-a 
constatat o crestere IRmediu de la 0.87 la 1.07, adica cu cca 23%, datorata exclusiv 
scaderii latentelor ierarhiei de memorii, deci a unei îmbunatatiri tehnologice si nu 
arhitecturale. Este înca o dovada ca progresele tehnologice vor aduce beneficii 
semnificative în cresterea performantei. În figura 5.33 se arata evolutia ratei medii 
aritmetice de procesare functie de diferite capacitati ale cache-ului secundar, pentru 
I-Cache=32 si D-Cache=128. Pentru un cache secundar de 256 intrari s-a obtinut 
IR=0.38, iar pentru unul de 4K intrari IR=0.75, deci o crestere de cca 97%. În 
figura 5.34 se arata evolutia ratei medii aritmetice de miss în cache-ul secundar, în 


aceleasi conditii cu cele din analiza precedenta. Pentru un cache secundar de 256 


intrari, a rezultat MR=54%, iar pentru 4K intrari a rezultat MR=8.45%, fapt ce 


explica cresterea globala de performanta anterior evidentiata. 
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Figura 5.34. Influenta capacitatii nivelului 2 de cache asupra ratei de miss 
Se observa ca metrica preferata in evaluarea de performanta a acestor 


arhitecturi neconventionale a fost una globala, relevanta, anume rata medie de 


procesare (IR), preferata metricii locale, nu intotdeauna de mare relevanta, numita 
rata medie de hit/miss in cache. 

În concluzie, aceasta cercetare în domeniul compromisului Harvard / non- 
Harvard într-un procesor MEM, este într-o deplina concordanta prin rezultatele pe 
care le furnizeaza cu cea realizata la nivel teoretic (analitic) în capitolul 4. Prin 
intermediul acestor investigatii, arhitecturile unificate apar într-o postura 
favorabila, noua, care le face atractive si din punct de vedere al performantei, nu 
numai al complexitatii structurale si al costurilor. Pâna în prezent era vehiculata 
ideea - nejustificata nicaieri în mod riguros - ca acestea sunt "depasite", datorita 
conflictelor structurale pe care le implica si deci a performantei scazute din acest 
punct de vedere. De asemenea, s-a prezentat o metoda de simulare valabila pentru 
determinarea principalilor parametri arhitecturali optimali pentru o arhitectura 
superscalara eficienta. Sau analizat si optimizat pe baza de simulare, arhitecturi 
avansate de procesare precum cache-urile "non - blocking", cache-urile de tip 
"victima", influenta nivelului 2 de cache, nfluenta instructiunilor "combinate", etc. 
Principiul metodei poate fi aplicat usor si cu succes în vederea optimizarii si altor 
componente arhitecturale în cadrul procesoarelor paralele de mare performanta, 


dupa cum de altfel se va arata practic în continuare pentru câteva probleme. 


5.3. MODELAREA SI SIMULAREA UNOR ARHITECTURI CACHE 
AVANSATE DE TIP HARVARD SI A PROCESELOR DE SCRIERE ÎN 
CACHE 


În acest paragraf se prezinta succint, bazat pe aceeasi metodologie de 
investigare de tip "trace driven simulation", o cercetare efectuata asupra unor 
arhitecturi cache avansate, exclusiv de tip Harvard de aceasta data, cu mapare 
directa, integrate în cadrul unui procesor paralel. În plus fata de cercetarea 
prezentata în paragraful anterior, s-a modelat si simulat blocul ca entitatea care se 
încarca respectiv evacueaza în / din cache. Capacitatea unui bloc s-a considerat a fi 
parametrizabila, variind între 1 si 32 cuvinte (1 cuvânt=32 biti). S-a simulat in 
acest caz un algoritm realist de lansare în executie a instructiunilor din bufferul de 
prefetch, de tip In Order, care tine cont de toate dependentele RAW între 
instructiunile din fereastra de executie. De asemenea s-au modelat procesele de 
scriere prin intermediul celor 2 strategii consacrate precum si procesorul specalizat 
de iesire DWB. Principalii parametri ai simulatorului implementat în acest scop 
sunt urmatorii: 

SIZE_IC - dimensiunea cache-ului de instructiuni în numar de locatii. O 
locatie memoreaza o adresa de instructiune sau data care este pe 4 octeti. 

SIZE_DC - dimensiunea cache-ului de date în numar de locatii (2j+k blocuri 
a câte 2! cuvinte / bloc, vezi figura 5.35). O locatie memoreaza o adresa de 
instructiune sau data care este pe 4 octeti. 

FR - rata de fetch - numarul de instructiuni extrase din cache pe 


perioada unui ciclu de fetch. 


IBS - marimea buffer-ului de prefetch - exprimata in numar de 
instructiuni. 

N_PEN -este numarul ciclilor de penalizare pentru un acces la memoria 
centrala, in conditiile in care perioada de ceas CPU este de un ciclu. 

NR_REG_GEN - numarul de seturi de registri generali folositi. 

IRmax - numarul maxim de instructiuni ce pot fi trimise simultan spre 
executie. 

NR_UNIT_LS - semnifica tipul cache-ului de date (uniport / biport) 

Comblnstr - (2/3) - semnifica posibilitatea de combinare a doua instructiuni 
primitive RISC dependente RAW respectiv a trei instructiuni dependente RAW 
într-una singura mai complexa. 

Dim_bloc - dimensiunea blocului din memoria cache de instructiuni, cuprins 
între 4 si IBS instructiuni masina. Pe cache-ul de instructiuni, dimensiunea blocului 
este de FR instructiuni, pe cel de date este parametrizabila si desigur independenta 
de FR. 

Arhitectura cache simulata, cu mapare directa si având parametrii i, j si k, 
este prezentata în figura 5.35 (AF reprezinta adresa fizica a procesorului). În ciuda 
timpului necesar translatarii adrese virtuale în adresa fizica, este preferata în 
adresarea memoriei cache aceasta din urma datorita faptului ca nu pune probleme. 
Este cunoscut faptul ca utilizarea adresei virtuale poate pune în principiu doua 


probleme relativ dificile: doua adrese fizice diferite provenite din aceeasi adresa 


virtuala care pun probleme de coerenta a cache-ului (de ex. la comutarea de task- 
uri, necesitând invalidarea cache-ului) sau doua adrese virtuale diferite care se 
mapeaza pe aceeasi adresa fizica (aliasuri), rezultând deci doua copii ale aceleiasi 
date în cache-ul virtual. Daca una se modifica, cealalta va avea o valoare gresita. 
La ambele probleme exista solutii consacrate (identificatori de procese - PID, 
"page coloring”- bitii c.m.p.s. ai aliasurilor sa fie identici, etc.), foarte bine 
documentate în literatura de specialitate [Hen96]. 


De mentionat ca pentru simularea si cercetarea în viitor a unor arhitecturi 


cache tip "2k -way set associative", mai eficiente datorita unor rate de interferenta 
mai reduse, câmpul Bloc pe (j+k) biti din figura 5.35, se divizeaza în doua 
câmpuri, unul codificând numarul seturilor din cache, pe j biti, iar altul numarul 
blocurilor dintr-un set, pe k biti. De asemenea, în acest caz mai general, adresarea 
cache-ului semiasociativ se va face exclusiv prin intermediul câmpului care 
codifica setul (pe j biti), în schimb câmpurile de cautare TagE si TagC extinzându- 
se pe (i+k) biti. Fiecare bloc dintr-un set va avea în plus atasat un bloc LRU (Least 
Recently Used), pentru evacuarea care se face acum în mod explicit pe baza 
algoritmului LRU. La limita, pentru un cache complet asociativ, câmpurile TagE si 
TagC se vor extinde pe (i+j+k) biti, cautarea în cache facându-se în mod pur 


asociativ, dupa câmpul TagE. 
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Figura 5.35. Schema memoriei cache optimizate in acest paragraf 


In esenta, concluziile cercetarii, bazata pe aceeasi metodologie de tip "trace 
driven simulation" ca si cea din paragraful precedent, sunt urmatoarele: 

S-a observat ca din punct de vedere al ratei medii de procesare (IR), in 
configuratia cu IBS=16, varianta cu FR=8 este cea optima. In medie cresterea de la 
FR=4 la FR=8 conduce la o crestere de 16% asupra ratei medii de procesare (IR), 
iar pe anumite benchmark-uri, ea poate conduce la cresteri de pana la 61% 
(bubble). Rate mai mari ale FR ar necesita mecanisme speciale pe procesul de 
fetch. Aceasta arata ca lungimea optimala a unui bloc in cache pare a fide 8 


cuvinte. 


Din punct de vedere al ratei de procesare, variatia capacitatii buffer-ului de 
prefetch peste valoarea de 2*FR instructiuni, nu are consecinte remarcabile. 
Rezultatele sunt aproape identice, rezultând hh medie o crestere asimptotica (sub 
1%) a performantei. Capacitatea a buffer-ului de prefetch trebuie deci sa fie minim 
2eFR. Asadar varianta optima se va alege în functie de rata de fetch, rezultat aflat 
în deplina concordanta cu cele obtinute pe baza pur teoretica (v. cap. 4). 

O concluzie generala ce se desprinde este aceea ca, rata de procesare nu 
creste întotdeauna în acelasi timp si liniar cu cresterea dimensiunii cache-ului de 
instructiuni, pentru un cache de date constant (128 locatii aici). Astfel functie de 
benchmark-ul folosit se obtine o dimensiune optima a cache-ului de instructiuni la 
64, 128 sau 256 dupa care rata de procesare ramâne constanta. Tinând cont de toate 
acestea s-a ales un cache de instructiuni optim de 128 locatii. 

Pentru cache-uri de date mai mari de 4K locatii, cu unele exceptii (puzzle, 
matrix, tree), cresterea în performanta devine asimptotica. Optimul performanta / 
cost rezultat în urma simularii pentru cache-ul de date este valoarea de 2048 locatii, 
valoare justificata prin cresterea în medie a performantei cu 23.26% fata de cazul 
în care SIZE_DC=1024; cresterea de performanta de la 2048 la 4096 de locatii 
reprezentând doar 8.6%. 

Pornind de la cele prezentate anterior, s-a determinat o configuratie optima 
din punct de vedere al ratei de fetch, buffer-ului de prefetch si a dimensiunii cache- 


ului astfel: SIZE IC=128 locatii, SIZE DC=2048 locatii, FR=8 instructiuni iar 


IBS=16 locatii. Ceilalti parametri (cache biport la date si numar nelimitat de 
registri) ramân aceiasi asa cum tam folosit si pâna acum 
(NR_REG_GEN=IRmax). 

În privinta optimizarii IRmax, concluzia ce se desprinde este ca variatia 
numarului de instructiuni ce pot fi trimise simultan spre executie peste 4, nu mai 
afecteaza rata de procesare. S-ar putea deci considera ca nu exista suficient 
paralelism care sa justifice IRmax=8 în benchmark-urile Stanford neoptimizate. În 
medie se observa o crestere a performantei cu doar 2% în favoarea cazului cu 
IRmax=8 fata de cel cu IRmax=4. Pentru o performanta superioara, schedulingul 
software este absolut necesar. 

În medie se observa o crestere a performantei odata cu cresterea numarului 
de registri (pentru 4 seturi de registri se obtine în general rata de procesare 
maxima). Diferenta de performanta este mai accentuata prin trecerea de la 2 seturi 
de registri generali la 3, decât prin trecerea de la 3 seturi de registri generali la 4. În 
cazul cache-ului de date uniport cresterea ratei de procesare de la doua la trei seturi 
de registri este de 6,14% iar de trei la patru seturi cresterea este de 2,79%, deci ca 
si în cazul cache-ului de date biport numarul optim este de trei seturi fizice de 
registri. Tinând cont de implicatiile hardware (cost / performanta) datorate unui 
numar mare de registri, si întrucât de la doua la trei seturi performanta creste în 
medie cu 10%( la arhitecturile unificate creste cu doar 3.5%) iar de la trei la patru 


seturi cu 3% ( la unificate doar cu 1.4%), consideram ca trei seturi de registri 


reprezinta solutia optima. În medie performanta se îmbunatateste în cazul cache- 
ului de date biport cu 12% (fata de numai 9% pe varianta optima a unui cache 
unificat pe instructiuni si date) , maximul atingându-se pe benchmark-ul bubble 
(61%), iar minimul 0,01% pe benchmark-ul matrix 

Se observa ca, tehnica de "combining" a instructiunilor dependente RAW, 
îmbunatateste performanta in cazul cache-ului biport în medie cu 8,51% (fata de 
4.43%- 5.4% în cazul unificatelor), valoare diminuata de faptul ca într-una din 
situatii bubble) performanta scade (cu 22,51%). Cache-urile de tip biport implica 
o rata medie de procesare mai mare cu 9,2% decât cele uniport pe varianta 
îmbunatatita cu tehnica de combining, fata de 11,9% pe varianta fara combining. 
Aceasta se datoreaza cresterii mai mari a performantei datorate tehnicii de 
combining la cache-ul uniport (11,9% fata de 9,2% la cache-ul de tip biport). 

Daca pâna acum s-a considerat procesul de scriere în cache transparent 
pentru procesor, totul executându-se într-o singura perioada de tact - de catre 
procesorul de iesire DWB (data write buffer) - indiferent de procesul de scriere (hit 
sau miss), în continuare se vor prezenta pe scurt rezultatele modelarii si simularii 
procesului de scriere în cache-ul de date D-Cache, prin prisma celor doua posibile 
strategii: "write back" si "write through". Cu "write through", informatia e scrisa în 
ambele locuri: în blocul din cache si în blocul din memoria principala. Prin "write 
back" informatia este scrisa doar în blocul din cache. Blocul din cache modificat 


este scris în memoria centrala doar când este înlocuit. "Write back" este preferata 


în majoritatea implementarilor actuale. Aceasta tehnica implica evacuare efectiva a 
blocului - cu penalitatile de rigoare - în memoria principala. Rezulta ca este necesar 
un bit Dirty asociat fiecarui bloc. Starea acestui bit indica daca blocul e Dirty 
(modificat cât timp a stat în cache), sau Clean (nemodificat). Daca bitul este Clean 
("curat"), blocul nu e scris la miss, deoarece nivelul cel mai de jos (inferior) are 
copia fidela a informatiei din cache. Daca avem citire din cache cu miss si bitul 
Dirty setat, atunci vom avea o penalizare egala în timp cu timpul necesar evacuarii 
blocului, la care se adauga timpul necesar încarcarii din memorie în cache a 
blocului necesar î continuare. La "write through" nu exista evacuare de bloc la 
cache-urile mapate direct, dar exista în schimb penalitati la fiecare scriere în 
memorie. 

Ambele tehnici ("write back" si "write through") au avantajele lor. Cu "write 
back", scrierile au loc la viteza memoriei cache, si multiplele scrieri în bloc 
necesita doar o scriere în nivelul cel mai de jos al memoriei, la evacuare. Cu "write 
through", miss-urile la citire nu conduc niciodata la evacuari în nivelul inferior, în 
plus fiind mai usor de implementat decât "write back". "Write through" are de 
asemenea avantajul ca, urmatorul nivel inferior contine majoritatea copiilor curente 
ale datei. Acest lucru este important pentru sistemele de intrare iesire (I/O) si 
pentru multiprocesoare. Tendintele sunt contradictorii: ele vor sa foloseasca "write 
back" pentru cache-ul procesorului si pentru a reduce traficul memoriei si vor sa 


foloseasca "write through" pentru a pastra cache-ul coerent si consistent cu nivelul 


inferior al ierarhiei de memorie . Evident, oricare din aceste doua strategii de 
scriere pot fi asociate cu cele de mentinere a coerentei cache-urilor în cadrul 
sistemelor multiprocesor, anume strategia "write invalidate" respectiv "write 
broadcast" [Hen96]. Nu intram aici în amanunte, aspectele de coerenta sunt bine 
documentate si foarte bine cunoscute în mai toate cartile generale de arhitectura a 
sistemelor de calcul [Hen96, Pat94, Sto93], în plus ele nu reprezinta subiectul 
acestei lucrari. 

În urma simularilor am obtinut în medie o diminuare a ratei de procesare fata 
de cazul unei scrieri ideale ca cea considerata în paragraful anterior, folosind 


' 


tehnica de scriere "write back" de 10.88%, iar în cazul folosirii tehnicii "write 
through” o scadere de 100.4%. Rezulta avantajul net al tehnicii de "write back", 
umbrit doar de faptul ca este mai dificil de implementat hardware. 

În continuare se vor prezenta succint câteva dintre rezultatele simularii unui 
mic procesor de iesire, pe care-l vom numi Data Write Buffer (DWB), o coada 
FIFO (First In First Out) de lungime parametrizabila, a carei valoare trebuie sa fie 
minim IRmax, si care s-a ales aici de 32 locatii. Fiecare locatie contine adresa de 
memorie (virtuala) si data de scris. Consideram ca DWB contine suficiente porturi 
de scriere pentru a sustine cea mai defavorabila situatie (STORE-uri multe, 
independente si simultane în fereastra IRmax fiind deci posibile), oferind deci 


porturi de scriere virtuale multiple. În schimb D-Cache va contine un singur port de 


citire (LOAD) si un singur port de scriere (STORE), reflectând o situatie cât mai 


reala. Consideram latenta de scriere a datelor in DWB de 1 tact iar latenta de 
scriere a datelor in D-Cache este de 23 tacte (parametrizabila). Cu DWB sunt 
posibile deci STORE-uri simultane, fara el acestea trebuind serializate cu 
penalitatile de rigoare. In plus DWB va putea rezolva prin "bypassing" foarte 
elegant hazarduri de tip "LOAD after STORE" cu adrese identice, nemaifiind deci 
necesara accesarea sistemului de memorie de catre instructiunea LOAD. Cresterea 
latentei procesorului de iesire DWB de la 2 la 3 cicli determina o diminuare a 
performantei de 11.63%. Rezulta cu cat va fi facut mai rapid procesul de scriere al 
DWB in cache-ul de date in cazul hit-ului, se va imbunatati rata de procesare. 
Utilizarea a doua porturi de citire fata de numai unul singur duce la o scadere a 
ratei de procesare cu aproximativ 5%. O concluzie desprinsa in urma simularii este 
aceea ca folosirea DWB in scopul rezolvarii hazardurilor de tip "LOAD after 
STORE" este utila doar in 5 din 8 cazuri, pentru 3 din benchmark-uri neexistând 
hazarduri de date la memorie. Studiind în conditii egale - cu DWB si fara DWB - 
(latenta_DWB=1=latenta instructiunilor executate cu hit în cache-ul de date, un 
singur port de citire si unul de scriere in cache-ul de date) rezulta avantajul 
concludent al buffer-ului DWB asupra performantei procesorului, prin tehnica de 
bypassing, determinând o crestere a ratei de procesare cu 17.87%. 

O importanta problema deschisa, neabordata aici, consta in stabilirea unei 
relatii juste intre scheduling si cache. Specialistii sustin in mod unanim ca 


schedulingul programelor obiect mareste viteza de executie a acestora, acesta fiind 


de altfel principalul scop al schedulingului. Pe de alta parte - o observatie practic 
trecuta cu vederea în literatura de specialitate - schedulingul mareste necesitatile de 
memorare ale programelor obiect în mod substantial. Aceasta este de natura sa 
mareasca rata de miss în cache-ul de instructiuni pentru programul reorganizat, 
ceea ce implica o scadere a eficientei executiei programului, pe de alta parte. Nu s- 
a stabilit înca unde se situeaza compromisul optimal între aceste doua fenomene 
antagoniste, cercetarile asupra schedulingului software eludând practic modelarea 
cache-urilor. Problema este dificila si din punct de vedere tehnic, dar se va încerca 


solutionarea ei de catre autor în cercetarile viitoare. 


6. CERCETARI PRIVIND PREDICTIA BRANCH-URILOR ÎN 
ARHITECTURILE SUPERSCALARE. 


În acest capitol vom prezenta doua contributii referitoare la importanta 
problema a predictiei instructiunilor de ramificatie in arhitecturile pipeline si cu 
paralelism spatial la nivelul instructiunilor. Prima cercetare încearca sa ofere un 
model analitic general de estimare a performantelor schemelor de predictie. Acest 
lucru este deosebit de important întrucât exista extrem de putine asemenea modele 
prezentate în literatura, toate fiind deficitare în opinia autorului. Utilitatea acestui 
model este evidenta, nemaifiind necesare simulari laborioase, cel putin într-o prima 
iteratie a procesului de proiectare. A 2-a investigatie, abordeaza pe baza de 


simulare software, problema extrem de interesanta si dezbatuta, a celor mai 


performante scheme de predictie la ora actuala, cele corelate pe 2 nivele. Se 
încearca pentru prima data, integrarea unei asemenea predictii hardware în cadrul 
arhitecturii HSA, dezvoltata la Universitatea din Hertfordshire, UK. Mentionam ca 
pâna în prezent, aceasta arhitectura se baza pe tehnici pur software de tip 
compensare "Branch Delay Slot" [Col94,Col95, Ste96]. De asemenea se prezinta 
rezultatele obtinute, aflate în deplina concordanta cu cele publicate în literatura de 


specialitate recenta. 


6.1. UN NOU MODEL ANALITIC DE ESTIMARE A PREDICTIILOR BTB 
(BRANCH TARGET BUFFER) 


Multiple sunt necesitatile dezvoltarii unor modele analitice generale de 
estimare a performantelor tehnicilor hardware de predictie a branch-urilor. La ora 
actuala, majoritatea estimarilor de performanta si deci de proiectare în acest 
domeniu, se bazeaza pe extrem de laborioase simulari ale unor arhitecturi BTB 
puternic parametrizate. Acestea presupun dezvoltarea unor instrumente sofisticate 
si dificil de creat, considerate ca fiind absolut necesare, cum ar fi: crosscompilator, 
reorganizator de program si simulator propriu-zis. Toate acestea se aplica unei 
arhitecturi particulare si unor benchmark-uri inevitabil particulare si ele. Astfel de 
abordari ale problemei proiectarii si evaluarii de performanta pentru diferite tehnici 
BTB pot fi gasite în multe cercetari [Lee84, Per93, Dub91, Yeh92] si pot fi 
considerate ca fiind deja "clasice". 

Exista putine abordari ale problemei, care sa încerce determinarea unor 
modele analitice generale aferente tehnicilor de predictie de tip BTB, unanim 
recunoscute si implementate la ora actuala. Asemenea încercari pot fi totusi gasite 
în [Hen96, Per93] si - cele mai mature si mai performante - respectiv în monografia 
[Cra92]. De altfel, aici, se si justifica pe larg necesitatea imperioasa a dezvoltarii 
unor asemenea metode care ar putea permite evaluari rapide, generale si usor 


adaptabile la modificari arhitecturale majore în cadrul arhitecturii cercetate. 


În continuare se va prezenta un model analitic general si original de analiza 
pentru arhitecturile cu predictie de tip BTB, implementate in procesoarele scalare 
RISC si respectiv in cele MEM. Modelul dezvoltat aici contine anumite principii 
utilizate de catre cel mai prolific cercetator in acest domeniu, Harvey G. Cragon, 
laureat al premiului Eckert Mauchly pentru merite deosebite in constructia de 
calculatoare, in monografia sa [Cra92]. Din pacate, modelele lui Cragon sunt 
ineficiente si partial nerealiste, întrucât presupun ca o instructiune de ramificatie 
care nu determina salt propriu-zis, trebuie introdusa în structura BTB chiar daca 
anterior nu s-a aflat acolo. Dupa cum s-a aratat si în [Per93], acest lucru este inutil 
si în plus implica reducerea performantei arhitecturii în mod considerabil. De 
asemenea, Cragon abordeaza problema exclusiv în cazul particular al unor 
arhitecturi scalare de procesoare. 

Modelul dezvoltat în continuare abordeaza problematica unui BTB clasic, 
integrat într-o arhitectura scalara sau de tip MEM. Analiza se bazeaza pe 
investigarea detaliata a urmatoarelor 4 cazuri posibile: saltul nu se afla în BTB si se 
va face, saltul m se afla în BTB si nu se va face, saltul se afla în BTB si este 
predictionat corect si respectiv saltul se afla in BTB dar este predictionat incorect. 
În continuare se va prezenta o analiza detaliata a fiecaruia din aceste cazuri în 
parte. 

1. Saltul nu se afla în BTB 


Deoarece instructiunea de salt / apel nu se afla în BTB în momentul aducerii 


sale din I-Cache, in mod implicit va fi prezisa ca nu se va face, procesarea 
continuând secvential in acest caz. Aici se disting 2 subcazuri : 

a. Saltul se va face (P=1) 

Am notat prin P probabilitatea statistica ca instructiunea de salt sa se faca. 
Uzual, pe programe generale, P ia valoarea tipica de 0.67 [Mil89, Cra92]. De 
asemenea se fac urmatoarele notatii: 

N = nivelul de procesare din structura pipeline in care se determina conditiile 
de salt si adresa efectiva destinatie a instructiunii de salt. În continuare, 
presupunem N > 2. 

d = numarul de cicli (tacti) necesari pentru citire (accesare) din BTB. În 
general, d = 0, cautarea în BTB facându-se chiar în faza IF. 

u = numarul de cicli necesari pentru scriere (actualizare) în BTB. În general 
u >= d si uzual u = 0 sau 1. 

i = instructiunea urmatoare în secventa, instructiunii de salt (B). 

B = instructiunea de salt curenta 

T = instructiunea destinatie la care se face saltul ( tinta). 

C = numarul de cicli necesari pentru refacerea contextului procesorului în 
cazul unei predictii incorecte (evacuari, actualizari, etc.). 

Cu aceste precizari, în acest caz, secventa de procesare a instructiunilor se va 


desfasura în timp ca în tabelul urmator : 


Tabelul 6.1. Procesarea în cazul în care saltul se face 


instructiunii de salt B este dat de relatia : 


CP =N -2 + d + Max (u, C) (6.1) 

Actualizarea în acest caz se refera chiar la introducerea saltului în BTB, de 
îndata ce el s-a facut. 

b. Saltul nu se va face (P = 0) 

Deoarece saltul nu se va face si întrucât el nu se gaseste în BTB, nu are sens 
sa fie introdus în structura BTB deoarece introducerea lui nu ar determina 
îmbunatatirea performantei, ci dimpotriva. În [Cra92] acest considerent nu se 
aplica, modelul suferind inutil penalizari si în acest caz. Procesarea temporala a 


instructiunilor s-ar desfasura ca mai jos (v. tabelul 6.2): 


Tabelul 6.2. Procesarea în cazul în care saltul nu se face 


In acest caz penalizarea este minima si este determinata de cautarea în BTB. 


Relatia de penalizare este: 


CP =d (6.2) 


2. Saltul se afla in BTB 

Aici se vor analiza detaliat cele 4 subcazuri posibile si anume : 

a. Ptt = 1 

Am notat prin Ptt probabilitatea ca instructinea de salt curenta sa fie 
predictionata ca se face si intr-adevar sa se faca. 

Aici se disting din nou 2 subcazuri, dupa cum adresa destinatie memorata în 
cuvântul BTB este ori nu este corecta. 

al. Adresa destinatie din BTB este corecta (Pac = 1). 

Notam cu Pac probabilitatea ca adresa din BIB sa fie corecta deci 
nemodificata în raport cu utilizarea ei anterioara. În practica Pac atinge valori mari 
cuprinse între 0.9 si 0.99. În acest subcaz procesarea este descrisa prin tabelul 


urmator. 


Tabelul 6.3. Procesarea în cazul în care Pac=1 


Si aici, ca si în cazurile urmatoare, actualizarea (u) semnifica modificarea 


starii automatului de predictie, în conformitate cu actiunea instructiunii de salt. 
Ciclii de penalizare sunt dati de relatia: 
CP=d+u (6.3) 


a2. Adresa destinatie din BTB nu este cea corecta (Pac = 0) 


Înseamna deci ca adresa efectiva a instructiunii destinatie memorata în BTB 
este diferita de cea actuala, de exemplu datorita unei adresari indirecte a 
instructiunii de salt in care continutul registrilor respectivi a fost modificat sau a 
fenomenului de interferenta a salturilor in BTB [Yeh92]. Procesarea instructiunilor 


se desfasoara in acest caz ca mai jos: 


Tabelul 6.4. Procesarea în cazul în care Pac=0 


Am notat prin T* instructiunea la care se face într-adevar saltul, 


corespunzatoare noii adrese modificate. În acest caz penalizarea va fi: 

CP =N - 2 + d + Max (u, C) (6.4) 

b. Ptn= 1 

Am notat prin Ptn probabilitatea ca saltul respectiv sa fie prezis ca se face si 
în realitatea sa nu se faca. În acest caz, procesarea temporala a instructiunilor este 


descrisa prin tabelul urmator. 


Tabelul 6.5. Procesarea în cazul în care Ptn=1 


Îl e Ia e IE 


E. 
N AR E 


Desigur ca si în acest caz instructiunea va ramâne în BTB pâna la evacuarea 


sa naturala. Ciclii de penalizarea sunt: 
CP =N - 2 + d + Maxtu, C) (6.5) 
c. Pnn = 1 
Am notat prin Pnn probabilitatea ca saltul respectiv sa fie prezis ca nu se face 


si într-adevar sa nu se faca. Procesarea este prezentata în tabelul 6.6. 


Tabelul 6.6. Procesarea în cazul în care Pnn=1 


CP=d+u (6.6) 
d. Pnt = 1 
Prin Pnt am notat probabilitatea ca saltul sa fie prezis ca nu se face si în 


realitate se va face. 


Tabelul 6.7. Procesarea în cazul în care Pnt=1 


In acest caz penalizarea este: 


CP =N - 2 + d + Maxtu, C) (6.7) 
Superpozitionând toti acesti cicli de penalizare (6.1-6.7) obtinuti în cazurile 


particulare prezentate anterior, obtinem numarul mediu de tacti de penalizare 


introdusi prin executia unei anumite instructiuni de ramificatie (CPM): 

CPM = (N - 2 + d + Max(u,c)) ((1 - Pbtb)P + Pbtb(Ptt(1 - Pac) + Ptn + Pnt)) 
+ Pbtb(d + u) (Ptt * Pac + Pnn) + d(1 - Pbtb) (1 - P) (6.8) 

Am notat prin Pbtb, probabilitatea ca instructiunea de salt adusa curent din I- 
CACHE, sa se afle memorata in BTB. Este clar ca obiectivul principal al 
proiectarii este minimizarea expresiei lui CPM si deci maximizarea performantei. 
Minimizarea lui CPM se obtine prin minimizarea parametrilor N, d, u, C, Pnt, Ptn. 
Este desigur dificila o solutie analitica pentru CPM minim in conditiile variatiilor 
rezonabile ale diversilor parametri. În cazul unui procesor pipeline scalar, 
performanta sa (rata de procesare) este data de relatia: 

IR = 1/(1 + Pb * CPM),[instr./tact] (6.9) 
unde Pb = probabilitatea ca instructiunea curenta sa fie o instructiune de salt 

În cazul unui procesor pipeline superscalar (MEM), putem scrie: 

CPI = CPlideal + CPM * Pb (6.10) 
unde CPlideal = numarul mediu de cicli / instructiune, daca ciclii de penalizare 
introdusi de branch-uri sunt nuli si daca predictia branch-urilor se considera 
perfecta. Evident ca CPI < 1. Rezulta imediat ca în cazul arhitecturilor 
superscalare, rata de procesare (IR) este data de relatia: 

IR = 1/CPI (6.11) 

O formula aproximativa dar utila a parametrului CPM, se poate deriva din 


cea exacta, anterior obtinuta, pe baza unor valori particulare considerate realiste a 


unora din multiplii parametri componenti si anume [Cha94, Per93, Cra92]: 

d=0,u=1, C=2, Pac = 1 (0.98 în realitate [Cra92]). 

Cu aceste particularizari, de altfel realiste, obtinem mai simplu: 

CPM= N((1-Pbtb)P + Pbtb(1-Ap)) + Pbtb Ap, (6.12) 
unde: Ap=Ptt + Pnn si reprezinta acuratetea predictiei. 

În acest moment devine interesant de precizat performanta unui procesor 
superscalar (MEM) care s-ar obtine în lipsa oricarei predictii a branch- urilor. În 


acest caz rezulta imediat, în mod succesiv, relatiile: 


CPM =P(N-1)+C (6.13) 
CPI = CPideal + Pb * CPM (6.14) 
IR =1/CPI (6.15) 


În concordanta cu [Per93, Cra92], se pot particulariza urmatorii parametri 
considerati realisti si reprezentativi: 

N = 3, Pb = 0.317, P = 0.67, Pbtb = 0.98 si CPlideal = 0.25 

În acest caz performanta arhitecturii superscalare in functie de gradul de 
acuratete al predictiei hardware (Ap) este prezentata în graficul urmator (figura 
6.1), pe baza relatiilor anterior determinate. Spre comparare, se prezinta o 
arhitectura superscalara cu predictie BTB fata de una fara predictie integrata. De 
remarcat ca pentru Ap = 0.7 rezulta rata medie de procesare IR = 1.31, iar pentru 
Ap = rezulta IR = 1.76, adica o crestere a performantei cu peste 34%. De altfel de 


la Ap = 0.9 la Ap = 1.0, performanta creste cu 12%, deci relativ semnificativ. La o 


acuratete a predictiei de 80%, extrem de usor de atins, performanta arhitecturii 
creste cu 88% fata de cazul fara predictie, iar la o acuratete de 90% absolut 
comuna, performanta creste cu 106% fata de cazul fara predictie. Este adevarat însa 
ca parametrii Pbtb si Ap nu sunt complet independenti cum de altfel se considera si 
în [Cra92], ambii depinzând de capacitatea BTB-ului, strategia de predictie 
utilizata, structura informatiei din BTB, etc. Totusi, consider asemenea grafice ca 
fiind deosebit de utile în estimarea rapida a performantelor asociate diversilor 
parametri arhitecturali. 

Ca un alt exemplu de aplicare a relatiilor analitice obtinute, considerând 
aceiasi parametri alesi si în plus acuratetea Ap = 0.93 tipica, obtinem o performanta 
realista: IRreal = 1.62 instr./tact. De mentionat ca în cazul unei predictii perfecte 
Ap, s-ar obtine IRperfect = 1.76 instr./tact, fata de IRideal = 4 instr./tact si asta 
numai datorita penalizarilor de accesare ale BTB-ului, relativ scazute si întârzierii 


calcularii adresei de salt (N = 3)! 


—@— predictionat 
— nepredictionat 


Figura 6.1. IR pt. un CPU fara si respectiv cu predictor de salturi 


De asemenea, se observa clar ca 0 acuratete a predictiei de 93%, foarte buna 
in schemele BTB neadaptive, diminueaza performanta fata de cazul unei acurateti 
perfecte a predictiei cu cca 9% în conditiile date, ceea ce este in acord cu alte 
cercetari [Yeh92]. Exista deci potential de imbunatatire a performantei 
arhitecturilor superscalare prin tehnici de predictie performante. Inca din 1992 s-au 
facut pasi importanti in acest sens prin dezvoltarea unor scheme de predictie 
adaptive pe 2 nivele corelate, care ating o acuratete de pâna la 97% masurat pe 
benchmark-urile SPEC. 

În concluzie la acest paragraf, s-a reusit o modelare analitica realista a 
performantei arhitecturilor MEM în functie de parametrii caracterisitici ai 
tehnicilor de predictie hardware a branch-urilor. Avantajele acestei metode fata de 


cele clasice bazate pe simulare, constau în faptul ca este generala, independenta de 


masina si genereaza in mod rapid parametrii legati de optimizarea predictiei, fara sa 
implice simulari laborioase. Prin particularizari realiste ale diversilor parametri, 
metoda furnizeaza rezultate concordante cu cele publicate în literatura de 


specialitate si obtinute pe baza de simulare. 


6.2. SIMULATOR DE PREDICTOR HARDWARE CORELAT PE 2 
NIVELE 


In acest paragraf se prezinta un simulator de tip "trace driven simulation", 
destinat predictiei hardware adaptive pe doua nivele, a instructiunilor de 
ramificatie. De precizat ca acest tip de scheme de predictie, dupa cum deja am 
aratat în cap.2, sunt cele mai performante la ora actuala în cadrul arhitecturilor 
MEM [Yeh92, Hen96, CheC96]. Acest predictor hardware este integrat, pentru 
prima data, în cadrul arhitecturii de procesor HSA care, initial, nu a fost gândita sa 
realizeze predictia hardware a ramificatiilor [Col95, Ste96], aceasta constituind 
ideea autorului acestei lucrari. Schema de principiu a predictorului implementat 


este prezentata în figura urmatoare (6.2). 


Tabela de 
predictii 


Automat | Adr. dest. 
predictie salt 


PCigy & Hist Reg 


Figura 6.2. Schema de predictie simulata 


Se va urmari deci analizarea in premiera, a fezabilitatii unui astfel de 
predictor integrat in cadrul arhitecturii HSA. Hist Reg reprezinta "registrul istorie" 
al predictiilor si contine valori binare semnificând comportarea ultimelor k 
instructiuni de ramificatie. În cadrul simulatorului dezvoltat, Hist Reg se comporta 
ca un registru de deplasare, are o lungime variabila cuprinsa între 6 si 14 biti si este 
vazut de program ca un întreg pe 2 octeti prelucrat la nivel de bit pentru fiecare 
rang al registrului. De asemenea sa parametrizat si lungimea variabilei PClow, 
utilizata în adresarea tabelei de predictii. Pentru tabela de predictii sa folosit o 
structura vectoriala de înregistrari. Fiecare înregistrare memoreaza adresa destinatie 
a saltului si respectiv starea automatului de predictie asociata contextului la acel 
moment dat. În cadrul simulatorului schema de automat de predictie utilizat poate 


fi stabilita initial de catre utilizator. Astfel se pot alege automate având între 2 si 16 


stari. 

Programul proceseaza trace-uri HSA speciale, provenite din compilarea si 
executarea benchmark-urilor Stanford. Aceste trace-uri speciale vor contine dupa 
cum este si firesc, toate instructiunile de ramificatie din benchmark, în ordinea 
executarii lor. Fiecare dintre aceste instructiuni de ramificatie din trace, au asociate 
PC-ul corespunzator si respectiv adresa destinatie a saltului, esentiala pentru 
verificarea corectitudinii predictiei. În realitate trace-urile HSA contin doar branch- 
urile care s-au facut, din motive de economie de spatiu, dupa cum am mai aratat de 
altfel. Au trebuit deci generate pe baza acestora si a surselor obiect HSA, trace-uri 
speciale continând si salturile inefective. O secventa dintr-un astfel de trace special 
destinat simularii predictoarelor, este prezentat în continuare, în formatul: tip 
branch, PC branch, adresa destinatie. 

BS 27 9 

BM 17 28 

BT 35 38 

NT 40 41 

BT 45 27 

BS 27 9 

BM 17 28 

În principiu, simulatorul dezvoltat functioneaza astfel: 


1. Initializare simulator 


Aici, utilizatorul va stabili numarul bitilor ce caracterizeaza registrul Hist 
Reg, PClow, precum si tipul automatului de predictie din cadrul tabelei de 
predictii. Tot acum se initializeaza cu zero adresele destinatie si starea automatului 
de predictie utilizat. 

2. Simularea propriu-zisa 

Se stabileste de catre utilizator benchmark-ul de tip trace care va fi utilizat. 
Din acest benchmark, se citesc secvential instructiunile de ramificatie si se 
compara predictia reala din trace cu cea propusa din tabela. Aici pot sa apara 3 
cazuri distincte: predictie corecta, predictie incorecta sau predictie incorecta 
datorata exclusiv adresei de salt incorecte dn tabela. Acest ultim caz se poate 
datora faptului ca adresa de salt din tabela a fost modificata de exemplu de catre un 
alt salt, avand astfel un fenomen de interferenta al salturilor dar pot fi si alte cauze 
posibile (RETURN-uri, salturi indirecte). În continuare se vor actualiza 
corespunzator registrul Hist Reg si respectiv locatia folosita din tabela de predictii. 

3. Generarea de rezultate 

La finele simularii propriu-zise se genereaza rezultate statistice semnificative 
precum numarul total de salturi executate, procentajul de predictii corecte, 
incorecte si respectiv afectate de interferente ale salturilor. În continuare se vor 
prezenta si analiza doar câteva dintre rezultatele obtinute prin exploatarea acestui 


simulator de predictor hardware pe doua nivele. 


6.3. REZULTATE OBTINUTE PENTRU O SCHEMA CORELATA DE 
PREDICTIE, INTEGRATA IN PROCESORUL HSA 


În continuare se prezinta câteva rezultate semnificative obtinute prin 
exploatarea simulatorului anterior descris pe 5 din suita benchmark-urilor Stanford. 
Mai jos (vezi tabelul 6.8) se prezinta procentajul instructiunilor de ramificatie în 
cadrul acestor programe precum si procentajul din numarul total al instructiunilor 
de salt care într-adevar sa determine un salt în program. Rezulta ca în cadrul 
acestor programe, în medie 15% din instructiuni sunt ramificatii. Dintre acestea, 


cca 78% se fac. 


Tabelul 6.8. Caracteristicile benchmark-urilor Stanford 


Benchmark Total instr. % Branch-uri Descriere bench 
iat mă == 
puzzle 804.620 25(91) Rezolva o problema de 
Il an El = 


bubble 206.035 20(75) Sortare tablou prin metoda 
bulelor 


fee gee ed 
Miser 643 ad Calcul recursiv de permutari 


queens 206.420 19(50) Problema de sah a celor 8 
regine 


72.101 17(65) Sortare rapida a unui tablou 
aleator 


ae | S 


Mi 149 15(76) Problema turnurilor din Hanoi 
aad 24(73) Sortare pe arbori binari 


In figura urmatoare (figura 6.3) se prezinta procentajul predictiilor eronate, 


obtinute prin exploatarea simulatorului pe benchmark-urile respective. Simularea s- 


a facut considerând o tabela de predictii având capacitatea 16kintrari, considerând 


registrul Hist Reg succesiv pe 10, 8 si 6 biti. 


PC & Hist Reg = 14 B Hist Reg = 10 
B Hist Reg = 8 


ae 
= 
N 
o 
= 
fo) 
= 
a 


Figura 6.3. Influenta lungimii registrului de istorie globala asupra performantei (10,8,6 biti) 
În aceste conditii s-au obtinut rate medii (armonice-HM) de miss de 7.06%, 
6.95% si 6.4% respectiv. Daca s-ar fi ajuns la Hist Reg pe 4 biti, s-ar fi obtinut o 


rata medie de miss de 7.07% ceea ce arata clar faptul ca, performanta optima se 


obtine pentru Hist Reg pe 6 biti si anume o acuratete a predictiei de 93.6%, 
comparabila cu cele obtinute prin cercetari consacrate [Yeh92, Per93]. Normal, cel 
mai bine s-a comportat benchmark-ul matrix (predictie corecta in 96.5% din cazuri) 
întrucât aici 97% din salturi se fac. În plus, acestea sunt deosebit de predictibile, ca 
în toate programele cu un caracter numeric accentuat de altfel. Programul "sort" 
(sortare rapida) este cel mai dificil de predictionat, fapt situat în acord cu cercetari 
care arata pe o baza pur analitica faptul ca practic nu se pot obtine pe acest program 
acurateti ale predictiei mai mari decât 75% [Mud98]. 

O problema interesanta care s-a dorit a fi studiata a fost urmatoarea: în ce 
masura predictiile, altfel corecte ca directie a saltului (taken / not taken), sunt 
afectate in mod negativ de modificarea adresei efective in tabela de predictii, 
datorita unor instructiuni RETURN, salturi indirecte, etc. ? La aceasta întrebare se 
raspunde în graficul din figura urmatoare (fig. 6.4). Simularea s-a realizat 
considerând Hist Reg de 10, 8 si 6 biti si s-au obtinut adrese efective modificate în 
5.16%, 4.89% si 4.73% din cazuri respectiv (medii armonice). Din nou optimul se 
obtine si din acest punct de vedere pentru Hist Reg pe 6 biti (simulari pentru Hist 


Reg pe 4 biti genereaza adresa gresita în 4.8% din cazuri). 
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Figura 6.4. Procentajul de predictii eronate datorate modificarii adresei tinta în tabele (10,8,6 biti) 
În continuare (fig. 6.5) se prezinta rata predictiilor eronate pentru un model 
având tabela de predictii doar de 1k intrari. În acest caz, pentru Hist Reg pe 6, 4 si 
2 biti s-au obtinut rate medii ale predictiilor eronate de 7.59%, 7.08% si respectiv 


7.42%. Rezulta deci o acuratete medie maxima de 92.92% a predictiilor în acest 


caz, obtinuta pentru Hist Reg pe 4 biti. 
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Figura 6.5. Influenta lungimii registrului de istorie globala asupra performantei (6,4,2 biti) 


În figura urmatoare (fig. 6.6) se prezinta în aceleasi conditii cu cele 
precedente, procentajul din totalul predictiilor care caracterizeaza predictii 
incorecte din cauza modificarii adresei saltului. S-au obtinut în acest caz procentaje 
medii de 5.48%, 4.92% si 5.33% din totalul predictiilor. Si aici performanta 
maxima se obtine pentru Hist Reg pe 4 biti. Din cele prezentate, precum si din alte 
cazuri particulare explorate cu ajutorul simulatorului implementat, rezulta ca 
optimul între gradul de corelare (Hist Reg) si capacitatea tabelei (adresata prin 
intermediul PClow & Hist Reg ), se obtine pentru lungimi ale Hist Reg de cca. 


40% din numarul total al bitilor de adresare tabela. 
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Figura 6.6. Procentajul de predictii eronate datorate modificarii adresei tinta în tabele (6,4,2 biti) 


Altfel spus, aici stabileste simularea compromisul optim între 2 procese 
complementare: gradul de corelare al saltului (Hist Reg "mare") si respectiv gradul 
de localizare al saltului (PClow "mare"). Suma celor doi parametri este fixata prin 
proiectare, determinând deci capacitatea tabelei de predictie, asadar compromisul 
optim între acestia trebuie gasit. Rezultatele acestei simulari demonstreaza foarte 
clar urmatorul proces: un grad de localizare scazut determina interferente ale unor 
salturi diferite la aceeasi locatie din tabela rezultând predictii eronate pe motiv de 
adresa de salt alterata, deci scade performanta. Pe de alta parte un grad de 
localizare ridicat determina un grad de corelare scazut si deci schema devine 
inefectiva în cazul unor salturi corelate, datorita nesituarii adecvate în context a 


predictiei. Si în acest caz performanta globala scade. Optimul este un compromis 


intre aceste doua situatii extreme, dupa cum a si rezultat in mod clar. Desigur ca 
fenomenul de interferenta, poate fi evitat partial prin cresterea gradului de 
asociativitate al schemelor de predictie, fapt care s-a si simulat de altfel pe o 
multitudine de cazuri, optimul de asociativitate al tabelei PHT fiind "4 way set". 
Acest grad de asociativitate creste acuratetea predictiei cu cca. 5% fata de cazul cu 
mapare directa, ceea ce este remarcabil. Prin adaugarea unui câmp de tag in cadrul 
cuvântului tabelei de predictii, care sa fie comparat dinamic în faza IF cu PChigh, 
se exclude posibilitatea maparii unor salturi diferite în aceeasi locatie din tabela 
(interferente). Ar mai ramâne nerezolvata doar problema acelor salturi care 
modifica dinamic adresa tinta (instructiuni de tip RETURN). Ea poate fi rezolvata 
de exemplu, prin implementarea unor stack-frame-uri diferite, asociate biunivoc 
diferitelor taskuri în curs de executie. Si aceasta solutie a fost evaluata prin 
simulare, efectul este deosebit, o crestere medie a acuratetii predictiei de 3 - 4%. 
Toate aceste solutii determina însa cresterea complexitatii si deci a costurilor de 
implementare, în spiritul unui etern compromis între performanta si preturi. Alte 
simulari laborioase au mai aratat urmatoarele aspecte importante: optimul 
capacitatii tabelei PHT este de 128 intrari, caz în care pentru cazul unei PHT cu 
mapare directa, optimul lungimii HRg este de 11 biti (rezultând o acuratete medie a 
predictiei de 88%). Schemele tip PAg se comporta la fel de bine ca si cele de tip 
PAp, prin urmare acestea din urma nu merita implementate nici din punctul de 


vedere al performantei. Comutarea de task-uri, simulata prin resetarea periodica a 


tabelelor de predictie dupa un numar prestabilit de instructiuni procesate, 
diminueaza acuratetea predictiei cu cca. 4%. Amanunte asupra acestei cercetari pot 
fi gasite în lucrarea autorului [Vin97b]. Asadar simulatorul construit genereaza 
solutia optimala pentru orice schema corelata de predictii. 

Un astfel de predictor integrat în cadrul procesorului HSA conduce la 
rezultate foarte bune, pe deplin comparabile cu cele prezentate în literatura si 
constituie o alternativa superioara compensarii statice a BDS-ului, propuse în 
cadrul acestui procesor [Col95,Ste96]. Simulatorul construit conduce la solutia 
constructiva optima de schema de predictie corelata pe 2 nivele sau chiar tip BTB, 
integrata într-o arhitectura superscalara. Se observa imediat ca particularizând 
schema de predictie corelata pentru lungimea HR egala cu zero biti, se obtine o 
schema de predictie clasica, de tip BTB. Simulatorul implementat permite 
urmatoarele câmpuri în cuvântul BIB: PChigh (tag), automat predictie 
parametrizabil ca tip, adresa tinta a saltului respectiv, opcode instructiune tinta 
(optional). În continuare se prezinta câteva rezultate, considerate ca fiind extrem de 


interesante, în cadrul acestei particularizari de tip BTB. 
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Figura 6.7. Accelerarea performantei datorate introducerii instructiunii tinta in BTB 


În figura 6.7 sa prezentat acceleratia S [%] determinata de introducerea 
instructiunii tinta în cadrul cuvântului din BTB. Simularea s-a realizat pe o schema 
având predictoare pe 2 biti de tip numaratoare saturate, capacitate 50 de intrari si 
ciclii de penalizare necesari restaurarii contextului procesorului în cazul unei 
predictii gresite CP=5 cicli. S-a constatat o accelerare medie armonica de 8.5%, iar 
media aritmetica de 12.25%, ceea ce este semnificativ si în acord cu alte rezultate 
publicate în literatura. În figura 6.8 se prezinta acuratetea predictiilor comparativ 
pentru o schema BTB cu tag si o schema corelata pe doua nivele. Se observa ca per 
ansamblu schema corelata pe doua nivele lucreaza ceva mai bine. În figura 6.9 se 
prezinta raportul (S%) între acuratetea obtinuta pentru un predictor corelat cu tag si 


cea obtinuta pentru un predictor coreht fara tag, ca cel din figura 6.2. S-a obtinut în 


media armonica S=29%, rezultat previzibil având in vedere ca schema cu tag 


elimina in buna parte interferentele branch-urilor, dupa cum am mai aratat. 
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Figura 6.8. Comparare scheme corelate - scheme BTB 
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Figura 6.9. Accelerarea de performanta introdusa de asociativitatea tabelei de predictie 


6.4. SPRE UN PREDICTOR NEURONAL DE RAMIFICATII 


Avand in vedere limitarile schemelor actuale de predictie evidentiate in mod 
critic si in capitolul 2 al acestei lucrari precum si metodele relativ simpliste 
conceptual, utilizate in mod unanim in predictia salturilor, autorul a propus ca 
alternativa conceptul de predictor neuronal (PN). Acesta se bazeaza in esenta pe 
utilizarea unei retele neuronale (RN) pe post de predictor global al tuturor salturilor 
din program. In RN de predictie vor intra, ca si in predictoarele clasice, cele 3 
informatii ortogonale de predictie (PC pe i biti, HRI pe | biti si HRg pe k biti), 
eventual impreuna cu PC-urile aferente fiecarui bit din HRg, asa cum s-a aratat in 
capitolul 2 al acestei carti. Pe baza procesarii acestor informatii binare, reteaua va 
predictiona printr-un bit sau doi de iesire, comportamentul viitor al saltului (taken / 
not taken). 

Într-o prima faza a acestei cercetari aflata abia la început, pentru o sondare 
rapida a eficientei acestei idei novatoare, sa folosit o RN adaptata de tip LVQ 
(Learning Vector Quantization), ultrasimpla [Koh95]. În principiu structura de 
predictie este compusa din doi vectori binari: Vt- asociat unei predictii de tip 
"taken" respectiv Vnt- asociat unei predictii de tip "not taken". Fiecare dintre acesti 
vectori binari are o lungime de (i+k+l) biti, în concordanta cu lungimea totala a 


celor 3 componente pe care se bazeaza predictia. Initial, Wnt este initializat cu zero 


logic iar Vt cu unu logic. Pe procesul de predictie, fiecare salt in curs de 
predictionat genereaza un vector binar X(t) pe (i+k+l) biti, în corespondenta cu PC, 
HRg si HRI pe care le are asociate la momentul respectiv. Vectorul (Vnt sau Vt) 
avand distanta Hamming minima fata de vectorul X(t), se numeste "vector 


invingator" (Vw- "winner"). Celalalt vector se va numi perdant (VL"loser"). 
i+k+l 

HD= DX! X, Vw, Y'=minim =>Vw - vector învingator (6.16) 

p=l 

Algoritmul de predictie adaptiv este descris de ecuatiile de mai jos: 

Vw(t+1) = Vw(t) + a(D[X(D - Vw(t)] (6.17) 

VI(t+1) = VI) (6.18) 

S-a notat cu a(t) pasul de învatare. În ecuatia (6.17) semnul "+" se refera la o 
predictie corecta iar semnul "-" la una incorecta. Metoda propusa face pentru prima 
data pe plan mondial legatura între problema predictiei salturilor in 
microprocesoarele de mare performanta si respectiv problema recunoasterii 
formelor, recunoscând în prima un caz particular al celei de a 2-a probleme. Forma 
de intrare (X) se clasifica într-una din cele 2 forme care se modifica adaptiv, Vt 
respectiv Vnt. Practic se înlocuiesc automatele de predictie deterministe de tip 
numaratoare saturate (uzual de ordinul câtorva sute) cu o singura RN de predictie. 
Comparând un predictor clasic de tip PAp usor modificat (MPAp) ca cel din figura 
6.10, cu un PN de tip LVQ pe baza simularii trace-urilor Stanford HSA, am obtinut 


urmatoarele rezultate încurajatoare, prezentate în tabelele de mai jos (tabelele 6.9 - 


6.13). Se observa ca diferenta de performanta este de doar cca. 1% in favoarea 
schemei clasice, fapt uimitor având în vedere simplitatea extrema a PN utilizat. 
Pasul optim de învatare (notat cu a în tabelul 6.9) pare a fi de 0.01. Optimismul 
autorului este bazat si pe faptul ca procesul de învatare este complet neoptimizat în 
aceasta prima implementare, practic învatarea PN realizându-se pe tot parcursul 
procesarii trace-ului. Momentan se lucreaza la determinarea unor algoritmi eficienti 


de învatare, dupa cum se va explica în mod succint mai jos. 
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Figura 6.10. O schema de predictie tip PAp modificat 
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Figura 6.11. Schema bloc a predictorului neuronal 


Tabelul 6.9. Acurateti ale predictiilor pentru diferiti pasi de invatare (i=2, j=3, k=3, 1=3) 


| ni se Rd să a al 


0.1 94.96 | 85.75 96.7 88.14 78.53 77.42 


89.21 88.31 


Tabelul 6.10. Performante comparative predictor neuronal - predictor MPAp (i=2, j=3, k=2, 
1=3) 
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Tabelul 6.11. Performante comparative predictor neuronal - predictor MPAp (i=2, j=3, k=3, 
1=3) 
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MPAp 84.98 | 96.48 97.76 81.53 74.93 89.76 


Tabelul 6.12. Performante comparative predictor neuronal - predictor MPAp (i=2, j=3, k=3, 
1=4) 
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Tabelul 6.13. Performante comparative predictor neuronal - predictor MPAp (i=3, j=3, k=3, 
1=4) 


Neuro 95.21 85.3 96.68 89.66 76.70 88.77 


95.68 96.40 | 98.20 82.38 89.66 | 90.06 


Mai departe am modelat si simulat un predictor neural de salturi bazat pe o 


structura de tip perceptron multistrat (MLP) cu algoritmul de invatare 
backpropagation, mai complex si mai inteligent decat anteriorul LVQ, prezentata 
in figura 6.13. La intrarile retelei intra PC-ul saltului si informatia de corelatie 
HRg, pe (l+k) biti. Aceasta schema s-a comparat prin simulare tip “trace driven’, 
cu una clasica de tip GAp (figura 6.12), avand un numar nelimitat de intrari si 
echivalenta informational. Special pentru a preinvata reteaua inainte de rularea 
benchmarkurilor (preinvatare de tip static), s-a realizat o statistica ca mai jos. 
Astfel, pt. fiecare benchmark in parte, s-a studiat pt. fiecare salt static si in fiecare 
context (pattern HRg) de aparitie a acestuia, comportamentul respectivului salt (se 


face/ nu se face). 


Branch PC HRg Taken Not Taken Taken(%) Not Taken(%) 


68 4055 121 41 74.69 25.31 
68 3935 127 30 80.89 19.11 
68 3453 17 138 10.97 89.03 
68 1525 124 107 53.68 46.32 
68 3925 109 143 43.25 56.75 
68 1367 124 360 25.62 74.38 
68 1373 210 234 41.30 52.70 
68 7165 4 3 57.14 42.86 
68 3061 3 0 100.00 00.00 
68 1399 72 200 26.47 73.53 
68 1501 142 181 43.96 56.04 
68 1909 126 196 39.13 60.87 
68 3541 44 174 20.18 79.82 
68 1213 4 1 80.00 20.00 


S-a considerat pragul suficient de polarizare de 75%. Cu alte cuvinte, 
salturile cu grad de polarizare mai mare de 75% sau considerat a fi suficient de 
predictibile si prin urmare, au rezultat urmatorii vectori de preantrenare a retelei, ca 
mai jos. 

Branch PC HRg Taken/Not Taken 


68 4055 1 


68 3935 1 


68 3453 0 
68 1367 0 
68 3061 1 
68 1399 0 
68 3541 0 
68 1213 1 


Asadar, reteaua e preantrenata in mod supervizat cu vectorii de intrare (PC & 
HRg) rezultati si fortând iesirea (Taken/ Not Taken) in mod corespunzator, prin 
modificarea ponderilor retelei neurale in conformitate cu algoritmul de invatare 
backpropagation [Gal93], foarte cunoscut si documentat în literatura inteligentei 
artificiale. Figurile 6.14 si 6.15 prezinta doar câteva rezultate semnificative 
obtinute in urma unor laborioase simulari, deosebit de incurajatoare si care arata 
clar forta conceptului novator introdus de noi în premiera mondiala, anume 
acela de predictor neural de ramificatii. Astfel se pune în evidenta eficacitatea 
învatarii statice a predictorului prin metoda propusa si schitata mai sus (Fig. 6.14) 
precum si superioritatea neta a predictorului neural fata de un predictor clasic 
puternic si idealizat (Fig. 6.15), care conduce h un câstig de cca. 4% în acuratetea 
predictiei, fapt absolut remarcabil în opinia noastra. 

În continuare, prin cercetari ulterioare, vom încerca imbunatatirea si rafinarea 


acestui concept introdus de noi, prin extinderea informatiei de intrare care am 


dovedit ca este insuficienta pt. o mare eficienta a predictiei si de asemenea vom 
studia influenta modului de structurare a informatiei la intrarea retelei. De 
asemenea vom analiza fezabilitatea implementarii hardware a unei asemenea 
structuri precum si posibilitatea implementarii predictorului in mod static, in cadrul 
schedulerului software. Totodata, vom insista pe gasirea unor noi algoritmi, mai 
eficienti, de invatare statica a predictorului neural, bazati pe utilizarea algoritmilor 
genetici in determinarea unui set initial optimal de ponderi pentru retea. Cu alte 
cuvinte ideea este ca in locul unui set initial de ponderi alese aleator în intervalul [— 
2/+k, 2/l+k] ca pâna acum, sa stabilim bazat pe utilizarea succesiva a unor 
operatori genetici consacrati, un set optimal de ponderi pentru reteaua neurala 


utilizata ca predictor. 
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Figura 6.12. O schema de predictie GAp, de capacitate nelimitata 
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Figura 6.13. Predictor neural bazat pe perceptron multistrat (MLP) 


Figura 6. 14 Predictor MLP preantrenat static vs. MLP fara preantrenare 
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Figura 6.15 Performanta predictor MLP vs. predictor clasic (GAp) 


7. CERCETARI IN OPTIMIZAREA PROGRAMELOR PE 
ARHITECTURILE MEM 


În cele ce urmeaza vom prezenta 2 investigatii originale, ambele referitoare la 
optimizarea programelor în arhitecturile cu paralelism redus. Prima cercetare 
abordeaza problema optimizarii unitatilor secventiale de program (basic - block) în 
cadrul unei arhitecturi superscalare simplificate si parametrizabile, definita de catre 
autor. Cercetarea se bazeaza pe un scheduler / simulator special conceput pentru 
acest scop, iar algoritmul de optimizare este unul de tip "List Scheduling", 
prezentat pe larg în capitolul 3 al acestei lucrari. Se prezinta comparativ si într-un 
mod cantitativ, beneficiile obtinute prin scheduling static local. De asemenea, prin 
prisma rezultatelor obtinute, se prezinta limitele optimizarilor locale în raport cu 
cele globale. A 2a investigatie încearca sa raspunda la o problema, credem noi, 
fundamentala si anume: mai putem spera rezultate spectaculoase de la acest 
domeniu ? Altfel spus, mai exista potential de performanta neexploatat relativ la 
schedulingul static ? Dupa cum se va vedea în paragraful 7.2, pe o baza de simulare 


de asemenea cantitativa, raspunsul meu va fi unul optimist. 


7.1. INVESTIGATII ÎN OPTIMIZAREA BASIC-BLOCK-URILOR 
PENTRU EXECUTIA PE ARHITECTURI SUPERSCALARE 


Problema optimizarii programelor în vederea procesarii lor pe arhitecturi 
superscalare si VLIW este una de mare interes în cercetarea actuala. Optimizarea 
se refera în general la 2 aspecte: optimizarea locala, adica în cadrul unitatilor 
secventiale de program (basic -block-uri) si respectiv optimizarea globala, adica a 
întregului program. Aceasta a doua abordare constituie momentan o problema 
deschisa, nefiind înca rezolvata la modul general si nici din punct de vedere al 
optimalitatii algoritmilor utilizati [Joh91, Ebci 88, Ste96]. Nu se va aborda aceasta 
problema în prezentul studiu, limitându-ma la investigarea câtorva aspecte legate 
de optimizarile locale, adica cele din cadrul basic-block-urilor. Dupa cum am 
prezentat în capitolul 3, problema optimizarii programelor în vederea executiei lor 
optime implica în general urmatoarele etape succesive mai importante: 

- determinarea grafului de control al programului de analizat. Aceasta se 
rezolva pe baza unor algoritmi de partitionare a programului în basic -block-uri; 

- determinarea grafurilor dependentelor de date si respectiv precedentelor 
pentru fiecare unitate; 

- optimizarea locala a basic-block-urilor. Aici se utilizeaza în general 
algoritmi cvasioptimali într-o singura trecere, de tip "List Scheduling" (LS) pe care 


îi vom folosi si noi în continuare; 


- optimizarea globala a programului. Aceasta se bazeaza pe algoritmi 
deterministi de tip "Trace Scheduling" [Hen96, Joh91] sau pe baza unor algoritmi 
euristici de tip "Percolation" [Col95]. 

În continuare se va prezenta o investigatie în domeniul optimizarii basic- 
block-urilor pentru o arhitectura RISC superscalara deosebit de simpla, definita de 
autor si configurabila. Schema bloc de principiu a acestui procesor superscalar 
virtual este prezentata în figura 7.1. Fiecare instructiune este procesata pipeline în 5 
stagii de executie succesive (IF, ID, ALU, MEM, WB). Arhitectura de memorie 
este una clasica, de tip Harvard (|-CACHE, D-CACHE). Bufferul de prefetch s-a 
considerat de capacitate practic nelimitata. Procesarea instructiunilor s-a considerat 
a fi de tip "In Order" aspect absolut necesar având în vedere ca programele sunt 
preoptimizate prin software. Procesorul detine 3 grupe de unitati de executie 
independente (ALU, SHIFT si unitatea LOAD/STORE) si 2 seturi de registri 
generali, unul principal si altul secundar, acesta din urma fiind utilizat in renaming- 
ul impus de algoritmul LS in vederea eliminarii hazardurilor de date de tip WAR si 
WAW (Write After Read, Write After Write). Cade în sarcina decodificatorului sa 
aloce in mod dinamic instructiunile din bufferul de prefetch spre unitatile de 
executie. Arhitectura este configurabila dupa cum urmeaza: 

- rata de fetch a instructiunilor cuprinsa intre 2 si 6 instructiuni simultan; 

- numarul de unitati ALU cuprins între 1 si 4; 


- numarul de unitati pentru deplasari si rotiri SHIFT intre 1 si 2; 


- o singura unitate LOAD / STORE; 


- numarul de registri generali cuprins intre 32 si 64. 
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Figura 7.1. Schema bloc a procesorului superscalar simulat 
Am considerat urmatoarele tipuri de instructiuni tipice, capabile de a fi 
executate de catre aceasta arhitectura; 
- instructiuni ALU având sintaxa: ALU Ri, Rj, Rk sau ALU Ri, Rj, #const 
(Ri destinatie); 
- instructiuni de tip LOAD având sintaxa LD Ri, (Rj) offset; 


- instructiuni de tip STORE avand sintaxa ST Rj, (Ri) offset; 


- instructiuni de deplasare si rotire avand sintaxa SHIFT Ri, Rj, #const si 
semantica: proceseaza (Rj) cu <#const > biti si introdu rezultatul in Ri. 

Se precizeaza ca toate instructiunile cu exceptia celor de tip LOAD se 
considra a avea latenta in executie de un singur tact. Instructiunile LOAD se 
considera ca au latenta de doua tacte. Unitatea LOAD s-a considerat a fi pipeline- 
izata. Obiectivul principal a fost acela de a aborda cantitativ eficienta 
schedulingului prin metoda LS pe aceasta arhitectura simplifcata. Pentru aceasta, s- 
a implementat un scheduler si un simulator în limbajul C pentru acest procesor 
parametrizabil. 

Mai întâi se prezinta pe scurt algoritmul LS utilizat în optimizare de catre 
programul scheduler / simulator implementat. Se considera pentru exemplificare un 
procesor RISC superscalar având 2 unitati ALU, o unitate SHIFT si o unitate 
LOAD / STORE. De asemenea se considera rata de fetch a instructiunilor ca fiind 
de 4. Benchmark-ul pe care vom face exemplificarea algoritmului (b1) este primul 
dintre cele 7 benchmark-uri pe care le-am exploatat prin programul scheduler si de 


optimizare. În continuare prezentam acest program: 


0: LD R1, (RO)8 

1: SHIFT R3, R2, #2 
2: ALU RI, R9, R10 
3: ALU R1, R1, R3 


4: SHIFT R2, R3, #4 


15: 


In urma analizei 


SHIFT 


LOAD 


LOAD 


ALU 


ALU 


ST 


ST 


ST 


R2, R1, R2 
RI, R6, R8 


RI, RI, R7 


RI, R1, #6 
RI, (R12 
R4, (R4)0 
RI, R4, R1 
R1, R1, R2 
R1, (R4)0 
R3, (R1)2 
R2, (R0)16 


acestui program, 


schedulerul 


construieste 


graful 


dependentelor si precedentelor de date ca în figura urmatoare (vezi figura 7.2): 


Figura 7.2. Graful dependentelor de date aferent programului considerat 
Avand in vedere resursele disponibile ale procesorului, acesta va executa 
programul bl asa cum se sugereaza in tabelele 7.1 si 7.2. De mentionat ca pentru 
aceasta, s-a implementat un algoritm de redenumire prin soft al registrilor, în 
vederea eliminarii hazardurilor de date de tip WAR si WAW. Astfel de exemplu, 
pentru acest program, în varianta optimizata, pe ramura 6-11 a grafului 
dependentelor / precedentelor se face redenumirea registrului R1 din setul principal 


cu un registru disponibil din setul secundar (Rt1). 


Tabelul 7.1. Prioritatea si ordinea inversa de executie a instructiunilor 


Tact Instr./prioritate 


12/6, 15/4 
5/3, 11/6, 10/2 
3/2, 4/2 


2/1, 1/1, 8/3, 9/5 
7/2, 0/2 


Tabelul 7.2. Executia secventei optimizate pe arhitectura superscalara considerata 


oe E 
Se 
a ee 
oe 
a II es E 
ee a 


De asemenea, instructiunea 12 devine în varianta optimizata: ALU RI, Rtl, 


7 


I0 
19 
110 
115 
114 
13 


R2. Se poate remarca faptul ca rata de procesare pentru programul initial este de 
1.14 instr/tact in timp ce rata pentru programul optimizat ajunge la 1.875 
instr./tact, rezultând deci o crestere a performantei prin scheduling cu 64% în acest 
caz. Totodata se observa usor ca utilizarea resurselor hardware este îmbunatatita 
radical prin scheduling. Utilizarea ALU a ajuns la 75%, a unitatii SHIFT la 38% si 
a memoriei de date la 75%. 

În continuare se vor prezenta câteva rezultate obtinute prin intermediul 
schedulerului si simulatorului implementat. Mentionam ca, asumând o predictie 
perfecta a instructiunilor de salt conditionat, cu anumite extinderi si perfectionari, 
simulatorul s-ar putea utiliza si pentru determinari cantitative în optimizarea 


globala. Acest program permite configurarea arhitecturii în limitele expuse, 


editarea si incarcarea unui program de test, optimizarea acestuia, simularea 
executiei sale, etc. La iesire, programul genereaza date statistice edificatoare 
privind performatele obtinute in urma procesarii, cum ar fi: rate de procesare 
pentru programele initiale si optimizate, coeficienti de utilizare pentru diversele 
resurse hardware, etc. Se prezinta rezultatele obtinute prin optimizarea si simularea 
în executie a 7 benchmark-uri (bl, ...,b7), de tip basic-block. Acestea au fost 
preluate din cadrul unor benchmark-uri consacrate precum Stanford, SPECint '95, 
etc. Structura acestor benchmark-uri este tipica din punct de vedere al distributiei 


grupelor de instructiuni si este prezentata in tabelul 7.3. 


Tabelul 7.3. Caracteristicile benchmark-urilor considerate 


Benchmar Nr.de instr. % LOAD/STORE 
k 


Nn 


nn 


a 


În primul rând am testat o configuratie minimala, având rata de fetch 4, o 
unitate ALU, o unitate SHIFT si o unitate LOAD / STORE. Dupa cum se observa 
în figura urmatoare (7.3), s-a obtinut o rata medie de procesare masurata pe testele 


initiale de 1.12 instr./tact. 


bi b2 b3 b4 b5 b6 b7 Av. 


Figura 7.3. Ratele de procesare pe programele initiale resp. optimizate (arhitectura minimala) 


În schimb, rata de procesare dupa optimizare a crescut la 1.22 instr./tact în 
medie, deci o crestere de 9%. A doua configuratie arhitecturala testata, numita 
"tipica" întrucât caracterizeaza multe procesoare superscalare de referinta [Joh91], 
s-a deosebit de cea minimala doar prin faptul ca detine 2 unitati ALU în loc de una 
singura. Dupa cum se observa în figura 74., rata de procesare pentru aceleasi 
benchmark-uri a crescut spectaculos dupa scheduling la 1.50 instr./tact, adica cu 
33% mai mult decât în cazul configuratiei minimale. În schimb performanta a 
ramas aceeasi pentru benchmark-urile neoptimizate. În fine, a 3a configuratie 
arhitecturala, maximala din punct de vedere al programului implementat, contine 4 


unitati ALU, 2 unitati SHIFT si o unitate LOAD / STORE. În acest caz rata de 


fetch a fost marita la 6 instructiuni. Se observa ca rata de procesare dupa 
scheduling a ajuns la 1.53 instr./tact, adica cu 35% mai mare fata de configuratia 
minimala, dar crescuta nesemnificativ in comparatie cu rata de procesare obtinuta 
pentru arhitectura tipica.(v. Fig. 7.5) S-au mai testat si alte arhitecturi intermediare, 
concluzia fiind aceeasi si in deplina concordanta cu referintele bibliografice: 
arhitectura tipica pare a fi optima din punct de vedere al raportului performanta / 


cost din punct de vedere al procesarii optimale a basic -block-urilor. 


bi b2 b3 b4 b5 b6 b7 Av. 


Figura 7.5. Ratele de procesare pe programele initiale resp. optimizate (arhitectura maximala) 


În continuare, s-a pus problema determinarii coeficientilor de utilizare 
aferenti resurselor hardware. Este clar ca prin scheduling utilizarea acestor resurse 
devine mai buna. Am definit coeficientul de utilizare al unei anumite resurse 
hardware (Ku) astfel: 

Ku = (Nu * 100%) / N * Eu (7.1), 
unde: 

Nu = numar de instructiuni care utilizeaza în faza de executie resursa "u". 

N = numar total impulsuri de tact în care se executa programul. 

Eu = numarul de unitati de executie de un anumit tip. 

Rezulta imediat 0% < Ku < 100%. 

Coeficientii de utilizare aferenti resurselor ALU, SHIFT si LOAD/STORE 
sunt prezentati in cele 3 figuri urmatoare (v. fig. 7.6 - 7.8), pentru benchmark-urile 
în cauza. Acesti coeficienti se prezinta comparativ pentru programele initiale si 
cele optimizate. În medie coeficientul de utilizare ALU este de 28% pentru 
programele neoptimizate si creste la 40% dupa optimizare. În mod analog, Kshift 
mediu este 21% respectiv 27% iar Kload/store mediu creste de la 41% la 54% 
respectiv. Ca si în cazul ratelor de procesare si în cazul coeficientilor de utilizare 
aferenti resurselor hardware performanta nu se îmbunatateste practic atunci când se 
trece la variante hardware mai complexe. Astfel, de exemplu, pentru configuratia 
maxima, utilizarea resurselor nu se va îmbunatati în cazul programelor initiale 


comparativ cu varianta tipica. Pentru programele optimizate, utilizarea resurselor 


se va imbunatati in mod nesemnifivativ cu un procentaj de (1.53/1.50 -1)*100% = 
2%. In concluzie, si din acest punct de vedere configuratia tipica pare a fi optima 


prin prisma raportului performanta/cost. 


bl b2 b3 b4 b5 b6 b7 Av. 


Figura 7.6. Ratele de utilizare a ALU pe programele initiale resp. optimizate 


bi b2 b3 b4 b5 b6 b7 Av. 


Figura 7.7. Ratele de utilizare a SHIFT pe programele initiale resp. optimizate 


bl b2 b3 b4 b5 b6 b7 Av. 


Figura 7.8. Ratele de utilizare a LOAD/STORE pe programele initiale resp. optimizate 


Ratele de procesare aferente unui procesor pipeline scalar compatibil, sunt 
prezentate în figura 7.9. Prin urmare acest procesor executa benchmark-urile 
neoptimizate cu o rata medie de 0.88 instr./tact. Rezulta deci ca arhitectura 
superscalara tipica este cu 28% (fara scheduling) si respectiv cu 70% (cu 
scheduling) mai rapida decât arhitectura scalara echivalenta care executa 
programele initiale. Prin scheduling global se comunica cresteri de performanta 
superioare de cca 300-400% [Ste96, Hwu95]. Dupa cum rezulta si din aceasta 
investigatie, rezultatele optimizarii basic -block-urilor sunt relativ modeste ducând 


la cresteri de performanta cuprinse doar între 9% sa 35%. 


bi b2 b3 b4 b5 b6 b7 Av. 


Figura 7.9. Ratele de procesare pt. un procesor scalar 


Aceasta se explica in principal prin faptul ca nivelul de paralelism al acestor 
unitati secventiale de program este limitat la 2-3 instructiuni dupa cum se arata in 
numeroase studii inca de pionierat. Rezulta ca sunt necesare metode de scheduling 
global cat mai agresive si eficiente. Acestea comunica cresteri de performante 
deosebite ajungându-se pâna la 200%-300%, dar în schimb cresc necesitatile de 
memorare ale programelor de 23 ori [Col95, Na93]. În acest sens, prezentam pe 
scurt un experiment pe care tam facut utilizând schedulerul si simulatorul HSA 
(Hatfield Superscalar Architecture), ambele dezvoltate la Universitatea din 
Hertfordshire, U.K. [Ste96, Col95]. Schedulerul este unul global si contine metode 
originale de optimizare de tip "percolation" pentru o arhitectura superscalara 
puternic parametrizabila (HSA-Hatfield Superscalar Architecture). Se prezinta mai 
jos (fig. 7.10) ratele de procesare obtinute prin simularea a 5 dintre benchmark- 
urile Stanford, cu si respectiv fara scheduling. Simularea a fost facuta pentru un 


model maximal al arhitecturii HSA continând câte 16 unitati de executie pentru 


fiecare grup semnificativ de instructiuni. Toate instructiunile au latenta de un 
impuls de tact cu exceptia celor de inmultire si impartire care se consuma in 3 


respectiv 32 de tacte. 


bubbl matri perm quee tree Av. 


Figura 7.10. Beneficiile optimimizarii globale asupra benchmark-urilor Stanford 

A rezultat ca gradul de utilizare al resurselor hardware este foarte scazut in 
acest caz. De exemplu, dintre cele 16 unitati ALU primele 3 sunt utilizate in medie 
cca. 32% din timp, urmatoarele 4 cca. 1% din timp iar restul de 9 unitati ALU sunt 
neutilizate! Ratele medii de procesare pentru programele Stanford neoptimizate 
sunt 1.63 instr./tact, iar dupa scheduling ajung la 3.21 instr./tact, deci o crestere a 
performantei de 97% fata de 33% cât s-a obtinut prin optimizarea doar a basic - 
block-urilor in aceasta investigatie. In opinia mea, aceasta crestere a performantei 
în urma optimizarii de cod este mai mult decât optimista având în vedere ca s-au 
considerat în simulare cache-uri ideale. Oricum, aceasta constituie înca o dovada ca 


pentru a obtine performante deosebite schedulingul trebuie sa fie de tip global, 


exploatand deci paralelismul intregului program si nu doar cel din cadrul unitatilor 
secventiale de program. 

O problema interesanta si putin dezbatuta in literatura este aceea de a 
determina gradul ideal de paralelism exploatabil de catre un procesor cu executii 
multiple ale instructiunilor. Cu alte cuvinte, exista oare suficient paralelism care sa 
justifice cercetari viitoare in scheduling si care sa poata duce la rezultate 
spectaculoase? Asupra acestei probleme se va concentra paragraful urmator, 


prezentând o metodologie originala si rezultatele aferente. 


7.2. INVESTIGATII ASUPRA LIMITELOR DE PARALELISM ÎNTR-O 
ARHITECTURA SUPERSCALARA 


7.2.1. PRINCIPIUL METODEI UTILIZATE ÎN INVESTIGARE 


În ultimii ani se manifesta un interes deosebit pe plan mondial în dezvoltarea 
unor metode si algoritmi de scheduling static global pentru arhitecturile MEM. 
Aceste schedulere - unele chiar integrate în compilatoare [Hwu95] - asambleaza în 
asa-numite grupuri, instructiuni independente din program, în scopul executiei 
simultane a instructiunilor apartinând aceluiasi grup. Aceasta investigatie realizata 
de grupul de la Universitatea din Hertfordshire împreuna cu autorul acestei 
monografii, se bazeaza pe arhitectura HSA (Hatfield Superscalar Arhitecture) si a 


fost prezentata în detaliu în [Pot98]. Arhitectura HSA dezvoltata la Universitatea 


din Hertfordshire, U.K., reprezinta o arhitectura superscalara - VLIW, hibrida deci, 
care aduce anticipat din ECache instructiuni multiple într-un buffer de prefech. În 
fiecare tact, logica de decodificare trimite In-Order spre executie din bufferul de 
prefech cât mai multe instructiuni independente pentru a fi executate în paralel. 
Optimizarea programelor se face static printr-un scheduler special conceput 
[Col95, Ste96]. 

Scopul acestei cercetari este de a "masura" gradul de ILP (Instruction Level 
Parallelism) existent in benchmark-urile Stanford, compilate special pentru 
arhitectura HSA utilizând compilatorul Gnu CC [Col96]. Aceste 8 benchmark-uri 
au fost scrise în C si propuse de catre John Hennessy de la Universitatea din 
Stanford, U.S.A., cu scopul de a constitui "numitorul comun" în evaluarea 
performantelor arhitecturilor ILP. Acestea sunt considerate deosebit de 
reprezentative pentru aplicatiile de uz general (non-numerice) si realizeaza, dupa 
cum am mai aratat, aplicatii generale precum: sortari prin diferite metode 
consacrate (bubble, tree si sort), aplicatii puternic recursive (perm - permutari, 
puzzle - joc, tower-problema turnurilor din Hanoi), si alte aplicatii clasice (matrix- 
procesari de matrici, queens - problema de sah a celor 8 regine). În urma compilarii 
acestor benchmark-uri C, s-au obtinut programe asamblare HSA (*.ins). 

Principiul metodei utilizate în investigare se bazeaza pe implementarea unui 
simulator TDS (Trace Driven Simulator), care sa lucreze pe trace-urile HSA (*.trc) 


ale benchmark-urilor Stanford. Aceste trace-uri reprezentând în principiu toate 


instructiunile masina HSA dintr-un program, scrise in ordinea executiei lor si 
memorate intr-un fisier, s-au obtinut pe baza simulatorului HSA dezvoltat anterior 
[Col95]. Acest simulator proceseaza benchmark-urile Stanford gata asamblate si 
genereaza parametrii completi aferenti procesarii precum si trace-urile in diverse 
forme. De precizat ca trace-urile utilizate contin intre cca. 72.000 si 800.000 de 
instructiuni masina HSA. În principiu TDS analizeaza secvential toate 
instructiunile dintr-un anumit trace HSA. Fiecarei instructiuni i se asociaza un 
parametru numit PIT (Parallel Instruction Time), semnificând numarul impulsului 
de tact în care instructiunea respectiva poate fi lansata în executia propriu-zisa. 
Aceasta înseamna ca în acel moment, operanzii sursa aferenti instructiunii 
respective sunt disponibili. Daca o instructiune urmatoare este dependenta RAW 
printr-un registru sau printr-o variabila de memorie de instructiunea curenta, atunci 
ei i se va aloca un nou PIT dat de relatia: 

PITnou = PITvechi + L, (7.2) 
unde: 

L = latenta instructiunii curente 

Acest proces de alocare PIT continua în mod similar, în N(N-1)/2 treceri prin 
trace, unde N reprezinta numarul de instructiuni din trace, pâna la finele acestuia. 
Instructiuni arbitrar plasate în trace pot avea acelasi PIT semnificând deci faptul ca 
pot fi executate în paralel. Se considera ca arhitectura are resurse (unitati 


functionale, registri, etc.) infinite astfel încât oricât de multe instructiuni 


independente pot fi executate in paralel la un moment dat. De asemenea, se ignora 
hazardurile false de tip WAR si WAW, considerându-se deci un "renaming" 
perfect, analiza anti-alias perfecta si o predictie perfecta a branch-urilor (model 
ORACLE). Asadar, un registru reutilizat ca destinatie în trace (primind deci o noua 
viata), este automat redenumit cu unul disponibil, pentru a elimina total hazardurile 
WAR si WAW si deci pentru a mari gradul de paralelism al trace-ului. În final se 
obtine gradul teoretic de paralelism disponibil: IRteoretic = N/ PITmax, unde N = 
numarul total de instructiuni din trace. De remarcat ca daca un asemenea model 
idealizat ar detine mecanisme de forwarding prin implementarea unor algoritmi de 
tip Tomasulo, s-ar reduce la maximum posibil citirile din seturile de registri. 
Astfel, s-ar diminua deci hazardurile structurale la setul de registri. 

Acest indicator (PIT) este esential întrucât va lamuri daca exista suficient 
paralelism care sa justifice în continuare cercetarile in scheduling, întrucât 
realizarile actuale cele mai performante comunica rate de procesare de doar pâna la 
3-4 instr./tact [Col95]. Dupa cum se va vedea, raspunsul va fi unul pozitiv. O alta 
problema, implicata de cele prezentate pâna acum, este urmatoarea: de ce nu se 
obtine IRteoretic în practica ? Raspunsul este: datorita unor limitari fundamentale, 
obiective, dar si datorita unor limitari artificiale, care e interesant sa fie cuantificate 
întrucât ele exprima doar neputinta mintii umane. O limitare fundamentala se refera 
la chiar conceptul de scheduling static. Acesta este nevoit sa fie uneori, în mod 


inevitabil conservator, datorita informatiilor necunoscute în momentul compilarii 


programului [Fra92, Col95]. Dintre celelalte limitari fundamentale amintim: 
hazardurile structurale, de date si de control. Limitarile artificiale sunt date de 
"conservatorismul", teoretic evitabil, al schedulerelor actuale si dupa cum vom 
arata, limiteaza serios performanta acestora. De exemplu, buclele (loops) constituie 
o astfel de limitare. Multe schedulere forteaza executia seria a iteratiilor unei 
bucle de program desi ar fi posibila paralelizarea acestor iteratii prin tehnici deja 
cunoscute si prezentate aici, precum cele de "loop unrolling" sau "software 
pipelining". De asemenea, majoritatea schedulerelor actuale nu permit executia 
instructiunilor dintr-o bucla pâna când toate instructiunile precedente buclei nu s-au 
executat. Analog, la iesirea din bucla. O limitare similara cu cea introdusa de bucle 
o introduc procedurile. Un alt exemplu îl constituie reorganizarea statica (executia 
Out of Order) a instructiunilor LOAD / STORE. Schedulerele actuale nu permit 
sau permit în limite foarte strînse acest lucru, întrucât problema dezambiguizarii 
(analiza antialias) referintelor la memorie nu este înca pe deplin rezolvata dupa 
cum de altfel am mai mentionat în capitolul 3 [Nic89, Hua94]. Din pacate un 
scheduler pur static nu poate distinge întotdeauna daca doua referinte la memorie 
sunt permanent diferite pe timpul executiei programului. În fine, o alta limitare de 
acest tip o constituie latenta mare a unor instructiuni sau memorii care se asteapta 
sa fie reduse în viitor prin progrese arhitecturale sau / si tehnologice. 

În cele ce urmeaza se vor cuantifica pierderile de performanta introduse prin 


aceste limitari, demonstrând totodata ca exista suficient potential în acest domeniu 


în care cercetarile sunt doar la început. Se mentioneaza ca exista câteva referinte 
bibliografice care abordeaza aceasta problematica [Lam92, Wall91]. Din pacate 
concluziile obtinute nu concorda între ele datorita unor metodologii de lucru foarte 
diferite. Astfel, de exemplu, David Wall (Digital) considera ca rata maxima de 
procesare pe un procesor superscalar nu poate depasi 7 instr./tact. Acest lucru se 
datoreaza faptului ca în modelul sau schedulingul este dinamic realizându-se de 
fapt exclusiv prin hardware. Având în vedere capacitatea limitata a bufferului de 
prefetch, rezultatul obtinut este absolut normal. Altii, pe modele mai agresive si 
prin scheduling static comunica potentiale mult mai optimiste cuprinse între 90 si 
158 instr./tact [Lam92]. În [Lam92] se abordeaza problematica gradului de 
paralelism posibil, prin prisma  relaxarii constrângerilor determinate de 
instructiunile de ramificatie. Se examineaza aportul cantitativ asupra gradului ILP 
adus de trei tehnici: executia speculativa cu predictie a instructiunilor de 
ramificație, analiza  dependentelor impuse de  ramificatii si respectiv 
multithreading-ul. 

Executia speculativa se refera la executia în paralel cu instructiunea de salt 
sau chiar anterior acesteia a unei instructiuni situata în program dupa instructiunea 
de salt. O tehnica relativ uzuala consta în executia speculativa a instructiunilor 
situate pe "calea ce mai probabila" (trace-ul cel mai probabil) în a fi executata. 


Fetch-ul speculativ al instructiunilor poate mari de asemenea considerabil gradul de 


paralelism. Desigur, in cazul predictiilor eronate ale instructiunilor de salt, efectele 
instructiunilor executate speculativ trebuie înlaturat. 

Analiza dependentelor ramificatiilor se refera h faptul ca toate instructiunile 
executate speculativ în cazul unei ramificații gresit predictionate, se anuleaza. 
Aceasta constrângere este uneori redundanta, conducând la actiuni inutile, 
consumatoare de timp. De exemplu în cazul urmator, asignarea "c=2;" nu depinde 
de salt si ca urmare poate fi executata speculativ în orice caz (indiferent daca saltul 
se face ori nu). 


if (a<0) 


Chiar daca prin hardware este mai dificil, totusi compilatorul (scheduler-ul) 
ar putea detecta aceaste "independente" de control si ca urmare elimina aceasta 
ineficienta. În caz contrar, efectul asignarii c=2 trebuie anulat, ceea ce este evident 
inutil, în cazul proastei predictii a saltului conditionat (if). Mai mult, printr-o 
analiza serioasa, executia speculativa în acest caz s-ar putea face peste mai multe 
ramificatii. 

Multithreading- ul se refera la capacitatea unei masini de a executa în paralel 
fluxuri distincte, independente, de instructiuni (procese) din cadrul unei aplicatii. 
Sa consideram secventa: 


for (1=0; 1<100; i++) 


if (A[i]>0) flux10; 
flux20; 

Într-un uniprocesor MEM va fi dificil si oarecum impropriu de exploatat la 
maximum paralelismul buclei flux1() împreuna cu a procesului flux2(), daca cele 2 
procese sunt independente de date, întrucât o ahitectura ILP nu are "viziunea" 
independentei acestor 2 functii. Acest lucru sar putea preta perfect însa pe o 
masina MIMD (multiprocesor) unde s-ar putea crea 2 perechi independente de tip 
procesor- proces. În continuarea analizei, autorii evalueaza gradul de paralelism 
disponibil în programele de uz general pe baza unei metodologii tipice, de tip 
"trace driven simulation". Evaluarile se fac pe mai multe "masini" abstracte dintre 
care amintim urmatoarele tipuri reprezentative împreuna cu particularitatile lor de 
procesare: 

BASE - masina MEM conventionala caracterizata de faptul ca o instructiune 
nu se executa pâna când ramificatia care o precede nu s-a încheiat. Instructiunile de 
salt se vor executa secvential, câte una pe ciclu (tact). 

CD (Control Dependence) - caracterizata prin aceea ca o instructiune nu se 
executa pâna când ramificatia de care depinde nu s-a încheiat. 

CD+ME (MultiFlow) - CD + ca se pot executa multiple salturi în paralel si 


out- of - order (în afara ordinii lor secventiale din program). 


SP (Speculation) - o instructiune nu se executa pâna cand ramificatia prost 
predictionata care o precede în trace nu s-a rezolvat. Cu alte cuvinte, aici salturile 
predictionate corect, ar permite executia speculativa. 

Pentru exemplificare, în figura 7.11 se prezinta o secventa de program cu 7 
instructiuni independente de date, precum si trace-ul aferent executiei. 
Instructiunile 1, 2, si 5 sunt ramificatii (BR- Branch). Se presupune ca ramificatiile 
2b si Sc din trace sunt predictionate gresit in trace, deci acestea nu ar permite 


executii speculative. 


5b (BR) 
2c (BR) 
3c 

5c (BR) 
6 


© ? 


Figura 7.11. Secventa de program si trace-ul aferent 


Mai jos, în figura 7.12, se prezinta executiile aferente acestui trace pe cele 4 


modele anterior prezentate: 


1 1,7 

i 
2a (ae 
5a,3a 5a,3a 
2b 2b 
5b, 4b 5b, 4b 
4 l 
2c 2c 
5c, 3c 5c, 3c 
4 
7,6 


Figura 7.12. Executiile trace-ului pe modelele BASE si CD 


CD +MF SP 
1,7 1, 2a, 3a, 5a, 2b 
2a  sa,6 Ab, 5b, 2c, 3c, 5c 
a | 
3a 
| | | 6,7 
4b 2c 5c 
l 
3c 


Figura 7.13. Executiile trace-ului pe modelele CD+MF si SP 


Dupa cum se poate observa din figurile anterioare, daca pe modelul BASE 
executia trace-ului s-ar face în 8 tacte, pe modelul CD+MF se face in 5 tacte iar pe 
modelul SP în doar 3 tacte. Simularea acestor modele pe benchmark- urile SPEC 
'92 au condus la urmatoarele grade medii de paralelism exprimate în [instr./tact] 


(v. tabelul 7.4): 


Tabelul 7.4. Grade medii de ILP masurate pe benchmark-urile SPECint '92 


CECE _ i 


Modelul ORACLE este unul perfect, în care singurele restrictii sunt date de 


A 


dependentele de date de tip "Read After Write" între instructiuni (in rest se 
considera predictie perfecta a salturilor, resurse hardware infinite, banda de fetch 
oricât de mare, redenumire perfecta a registrilor în vederea eliminarii conflictelor 
de nume, etc.). Concluzia ar fi ca exista un "semantic- gap" între performantele 
reale la ora actuala (1-2 instr./tact) si cele teoretic posibile. "Vina" este doar a 
schedulerelor actuale, extrem de conservatoare în privinta instructiunilor de 
ramificatie. Progresele în acest domeniu, care tin doar de "inspiratia" celor care se 


ocupa de aceste optimizari, nu vor fi în zadar pentru ca, se pare, potential exista. 


7.2.2. DETERMINAREA GRADULUI TEORETIC ILP SI A INFLUENTEI 
DIFERITELOR LIMITARI ASUPRA ACESTUIA 


S-a considerat un procesor HSA cu resurse infinite, predictor de branch-uri 
perfect, "renaming" perfect al registrilor si dezambiguizare perfecta a referintelor la 
memorie. Asadar, timpul de executie este restrictionat doar de catre dependentele 
reale de date. Latenta tuturor instructiunilor s-a considerat a fi de doar un tact, cu 
exceptia celor de tip DIV (impartire) care este 32 tacte si respectiv MUL 


(inmultire), 3 tacte. 
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Figura 7.14. Gradul ILP mediu pe modelul Oracle 
Asadar, pe un model hibrid superscalar - VLIW idealizat, media armonica a 
ratelor de procesare este de 19.45 instr./tact (media aritmetica ar fi de 55 
instr./tact). Toate raportarile ulterioare se vor face relativ la acest model de baza. 
În [Vas93] se arata ca sa reusit proiectarea si implementarea în tehnologie 
CMOS a unor unitati ALU complexe cu 3 intrari si care nu impun marirea 


perioadei de tact a procesorului comparativ cu o unitate ALU clasica având doar 2 


intrari. Acest fapt a condus la ideea unor instructiuni ALU combinate care sa 
contina trei operanzi sursa in loc de doar doi. Asadar, ar cadea in sarcina 
schedulerului sa combine 2 instructiuni ALU dependente RAW intr-una singura 
combinata. Mai precis o secventa de 2 instructiuni dependente RAW printr-un 
registru, ca mai jos: 

ADD RI, R2, R3 

ADD R5,RI1, R9 
va fi transformata de catre scheduler într-o instructiune combinata care va avea 
acelasi timp de executie: ADD R5, (R2, R3), R9. Aceasta tehnica, posibil de aplicat 
atât prin hardware cât si prin software, ar putea fi deosebit de agresiva întrucât ar 
actiona asupra unei limitari considerata pâna acum fundamentala si deci imposibil 
de depasit, anume hazardul RAW între doua instructiuni. Mai mult, cred ca 
eventualul impact negativ asupra perioadei de tact a microprocesorului este nul, 
având în vedere ca aceasta perioada de tact este dictata de procese mult mai lente 
precum cele legate de accesarea memoriilor cache de exemplu. 

Se prezinta în continuare (v. figura 7.15) câteva evaluari cantitative ale 
acestei tehnici noi, pe arhitectura HSA si trace-urile Stanford. Modelarea s-a bazat 
pe atribuirea aceluiasi PIT pentru 2 instructiuni dependente RAW si care pot fi 
colapsate într-una singura, pe baza unor reguli precise. Dupa cum era de asteptat, 
instructiunile combinate genereaza o crestere semnificativa a performantei, mai 


precis cu 60% fata de modelul precedent, obtinându-se o medie armonica de 31.27 


instr./tact. Consider acest câstig ca fiind suficient de ridicat încât ideea 
instructiunilor combinate, implementabila atât prin scheduler static cât si prin 
hardware, sa "prinda teren" în viitor. O cercetare detaliata a autorului în colaborare 
cu grupul de arhitecturi avansate de la Universitatea din Hertfordshire, Marea 
Britanie, asupra efectului sinergic pe care instructiunile combinate îl aduc 
împreuna cu utilizarea altor tehnici agresive de procesare, a fost publicata în cadrul 
unei prestigioase conferinte internationale asupra sistemelor de calcul paralele 
(International Conference on Massively Parallel Computing Systems - MPCS '98), 


desfasurata în Colorado Springs, S.U.A. [Pot98]. 
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Figura 7.15. Gradul ILP mediu pe un CPU cu instructiuni combinate 
În continuare, se vor determina pierderile cantitative de performanta pe care 
diversele limitari artificiale le implica si se vor analiza pe scurt aceste rezultate. 


Mai întâi se va determina cresterea de performanta în ipoteza ca toate instructiunile 


masina - inclusiv cele de tip MUL si DIV - ar avea latenta de un tact. Reamintesc 
ca aceste instructiuni MUL si DIV s-au considerat a avea latente de 3 respectiv 32 
de tacte. Cu alte cuvinte, voi incerca sa raspund la urmatoarea intrebare: vor aduce 
viitoarele progrese in eficienta algoritmilor de inmultire si impartire progrese 
semnificative, pe benchmark-urile de tip intreg ? Raspunsul cantitativ la aceasta 
intrebare este dat de urmatoarea figura, obtinuta pe baza metodei de analiza si a 


simulatorului implementat în acest scop. 


50 
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Figura 7.16. Influenta latentei instructiunilor MUL si DIV asupra gradului de paralelism 

S-a obtinut o medie armonica de 20.57 instr./tact, deci constatam o crestere 
cu doar 5.7% fata de modelul de baza, ceea ce arata clar ca reducerea latentei 
instructiunilor DIV si MUL nu va putea aduce cresteri spectaculoase de 


performanta în programele de uz general. 


Se va incerca acum sa se determine in mod cantitativ, degradarea ratei de 
procesare ideale atunci cand exista simultan doua limitari, specifice schedulerelor 
actuale: instructiunile dintr-o bucla nu se vor lansa in executie pana cand toate 
instructiunile anterioare nu se vor fi terminat si respectiv instructiunile care 
urmeaza unei bucle nu se vor lansa in executie pana cand toate instructiunile din 
bucla nu s-au lansat deja in executie. Cu aceasta restrictie am obtinut urmatoarele 


rezultate prezentate in figura 7.17. 


0 
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Figura 7.17. Limitarea ILP introdusa de barierele pe care le impun buclele de program (intrare/iesire) 


Rezulta deci IR = 8.72 instr./tact, fata de idealul IR = 19.45 instr./tact obtinut 
pe modelul de baza, adica o degradare a performantei cu 123%, ceea ce reprezinta 
enorm. lata de ce se impun in mod absolut necesar noi tehnici de paralelizare ale 
buclelor de program, întrucât acestea reprezinta o limitare majora în calea obtinerii 


unor performante superioare în schedulingul global. În continuare se va determina 


degradarea de performanta introdusa de fiecare componenta: limitarea la intrarea in 
bucla si respectiv la iesirea din bucla pentru a analiza contributia fiecareia in parte 


la degradarea ratei de procesare (v. figura 7.18). 
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Figura 7.18. Comparatie între limitarile buclelor de program pe "intrare" resp. pe "iesire" 

Se constata ca ratele medii armonice sunt cvasiegale in ambele cazuri, adica 
9.61 respectiv 9.19 instr./tact, ceea ce arata ca ambele restrictii sunt practic la fel de 
importante. O alta limitare ar consta in fortarea executiei seriale a tuturor iteratiilor 
unei bucle, asadar ignorarea paralelizarilor in interiorul buclei prin tehnici de tip 
"Loop Unrolling" si "Software Pipelining". Rezultatele obtinute in acest caz se vor 


prezenta in continuare (Fig.7.19). 
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Figura 7.19. Gradul ILP considerând serializarea executiei iteratiilor din buclele de program 


Scaderea de performanta devine acum realmente dramatica întrucât de la o 
rata ideala de 19.45 instr./tact s-a ajuns la una de 2.84 instr./tact, ceea ce înseamna 
o degradare a performantei cu 584%! Aceasta degradare se datoreaza exclusiv 
serializarii executiei buclelor, ceea ce arata clar importanta implementarii unor 
tehnici performante de optimizare a buclelor de program, întrucât aici se petrece 
cea mai mare parte a executiei unui program. 

Se doreste în continuare, sa se determine degradarea de performanta relativa 
la modelul de baza, pe care o implica o executie In Order a instructiunilor de tip 
LOAD si STORE, deci se simuleaza o noua restrictie constând în incapacitatea 
totala a schedulerului de a face analiza antialias a referintelor la memoria de date. 


Aceasta din pacate este o caracteristica a majoritatii schedulerelor actuale. 
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Figura 7.20. Gradul ILP considerând executie In Order a instructiunilor LOAD si STORE 


Cu alte cuvinte, am modelat o procesare a instructiunilor, fara nici un 
mecanism de dezambiguizare a referintelor la memorie, deci cu fortarea executiei 
In Order a instructiunilor LOAD respectiv STORE. Din nou se observa o scadere 
de performanta extrem de ridicata, de la 19.45 la doar 4.00 instr./tact, deci o 
reducere a performantei cu 380% (v. figura 7.20). Se impun deci clar metode mai 
puternice de dezambiguizare a referintelor la memorie comparativ cu cele deja 
existente. 

Se stie ca procedurile implica salvari / restaurari laborioase de contexte si 
totodata sunt mari consumatoare de timp. "In lining"-ul acestora ar mari 
semnificativ lungimea codului, dar ar micsora timpul de executie. În cele ce 
urmeaza prezentam rezultatele obtinute pentru un "in - lining" perfect al tuturor 


procedurilor. Acest model ignora toate instructiunile de salvare/restaurare asociate 


procedurilor existente in programele benchmark utilizate. Rezultatele obtinute prin 
simularea acestei idei, sunt prezentate in figura 7.21. Se constata o qestere a 
gradului de paralelism de la 19.45 la 28.24 instr./tact, adica cu 45% mai mult, ceea 
ce este deosebit de semnificativ. Concluzia autorului este ca trebuiesc gasite aici 
solutii de compromis de tip "in - lining" selectiv, pe baze euristice, întrucât se pare 
ca beneficiile asupra performantei ar putea sa fie majore. O euristica relativa la 
aceasta selectie ar trebui sa tina cont în opinia mea de lungimea procedurii si de cât 
de des este ea apelata. De asemenea, în acelasi sens, este important daca procedura 


respectiva mai apeleaza la rândul ei alte proceduri. 
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Figura 7.21. Gradul ILP considerând macroinstructiuni în locul procedurilor 
În concluzie la acest ultim paragraf, în concordanta cu aceste investigatii, 
domeniul ILP si în special optimizarile programelor ILP, are un potential de 


dezvoltare cu totul deosebit, performanta arhitecturilor MEM putând fi serios 


îmbunatatita în opinia autorului, in principal prin dezvoltarea urmatoarelor tehnici 
de optimizare ale programelor: 

- executii speculative ale instructiunilor prin analiza performanta de catre 
scheduler a dependentelor impuse de ramificatii si prin predicare 

- multithreading-ul ca alternativa superioara la ILP 

- tehnici agresive de paralelizare a buclelor de program 

- tehnici de utilizare hard/soft a instructiunilor combinate în vederea 
eliminarii dependentelor reale de date. Tot aici consideram ca deosebit de utila o 
viitoare generalizare a acestor mecanisme de instructiuni combinate. 

- tehnici de "in - lining" selectiv al procedurilor 


- noi tehnici de analiza antialias a referintelor la memorie 
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GLOSAR 


În cele ce urmeaza se prezinta într-un mod succint si pragmatic doar acei 
termeni de specialitate folositi relativ des în lucrare si al caror înteles — crede 
autorul — merita explicitat cititorului. Pragmatismul descrierii termenilor se refera 
la faptul ca autorul +a definit exclusiv în acceptiunea stricta care le-a fost data in 
aceasta carte, chiar daca majoritatea acestor termeni au interpretari si semantici 
multiple în spectrul larg al literaturii stiintifice din domeniul tehnologiei 
informatiei. Am folosit si termeni în limba engleza datorita faptului ca unii dintre 
acestia sunt deja consacrati si totodata pentru a obisnui cititorul cu terminologia 
acestui domeniu, a carui geneza si dezvoltare se regasesc — din pacate — practic 


exclusiv în literatura de specialitate americana. 


Antialias (Disambiguation) — analiza hard sau/si soft a adreselor de acces la 
memoria de date în vederea procesarii paralele sau Out of Order a instructiunilor cu 


referinte la memorie dintr-un program.[3.6.2], [3.7], [3.11], [5.1], [7.2.1], [7.2.2] 


Basic — block (unitate secventiala de program) — secventa de instructiuni 
care nu contin salturi si care nu constituie destinatii pentru nici o instructiune de 


salt. [2.4.4.2], [3.6], [3.6.1], [3.6.4], [3.7], [3.7.1], [3.10] 


Benchmark -— program destinat testarii si evaluarii performantei unei 
anumite arhitecturi de calcul. Sunt în general standardizate de catre organismele 
internationale de profil. [1], [2.4.4.3], [3.1], [3.4], [3.10], [4], [4.1.1], [4.3], [5.1], 


[5.2], [5.3], [6.1], [6.2], [6.3], [7.1], [7.2.1], [7.2.2] 


BTB (Branch Target Buffer) — mica memorie cache integrata in procesor 
care memoreaza automatele de predictie si adresele destinatie aferente 
ramificatiilor de program. Utilizat în predictia salturilor. [1], [2.4.4.3], [3.5], [3.10], 


[4.3], [4.4], [4.5], [5.2], [6.1], [6.3] 


Buffer de reordonare — structura hardware implementata în cadrul 
procesoarelor superscalare în vederea facilizarii executiei Out of Order prin 
redenumire dinamica a resurselor precum si a implementarii unui mecanism precis 


de tratare a exceptiilor. [3.4] 


Bypassing — proces de transfer al rezultatului aflat la iesirile unei unitati de 


executie, direct la intrarea unei alte unitati de executie care are nevoie de acel 


rezultat, eliminându-se deci asteptarile legate de înscrierea rezultatului în setul de 


registri respectiv citirea acestuia din acelasi set logic. [2.4.4.2], [3.9], [3.10], [5.3] 


Cache — concept arhitectural care desemneaza o memorie de capacitate mai 
mica, mai rapida si mai scumpa per octet decât memoria principala, situata din 
punct de vedere logic între procesor si aceasta. Memoria cache este gestionata - în 
general prin hardware — astfel încât probabilitatea statistica de accesare în cache a 
unei date de catre procesor (rata de hit), sa fie cât mai mare. Se diminueaza deci 
timpul mediu de acces la memoria principala. Astfel se reduce din “prapastia 
semantica” între viteza tot mai mare a procesoarelor si respectiv latenta prea 
ridicata a memoriilor DRAM actuale. Memoriile cache sunt realizate în tehnologii 
de mare performanta fiind uzual integrate în procesor. Conceptul este însa de o 
mult mai larga generalitate având aplicatii si în sistemele de operare si în aplicatiile 
software (vezi memoria virtuala în acest sens). [1], [2.1], [2.2], [2.3], [2.4.2], 
[2.4.4.1], [2.4.4.2], [2.4.4.3], [3.1], [3.5], [3.6], [3.10], [4], [4.1], [4.1.1], [4.1.2], 
[4.2.1], [4.2.1.1], [4.2.2.1], [4.3], [4.4], [5.1], [5.2], [5.3], [6.1], [7.1], [7.2.1], 
[7.2.2] 

- Princeton (non — Harvard) — arhitectura de memorii cache unificate 


(comune) pe spatiile de instructiuni si date. [1], [4], [4.1.2], [4.2.1.1], [5.1], [5.2] 


- Harvard — arhitectura de memorii cache fizic separate pe spatiile de 
instructiuni respectiv date. [1], [2.3], [2.4.2], [24.4.1], [4], [4.1.2], [4.2.1.1], 


[4.2.2.1], [5.1], [5.2], [5.3], [7.1] 


Cale critica (Critical path) — drumul cu latenta maxima din cadrul unui graf 


al dependentelor de date între instructiunile unui program. [3.6.3] 


CISC (Complex Instruction Set Computing) — termen generic care 
desemneaza o arhitectura de procesor situata in general in contradictie conceptuala 
cu arhitectura de tip RISC. Pâna în anii ‘80, procesoarele CISC (Intel, Motorola, 
DEC VAX11-780, IBM — 360, etc.) erau caracterizate de o disjunctie între 
structura hardware si setul de instructiuni masina, respectiv aplicatiile software 
scrise în limbaje evoluate, care rulau pe aceste procesoare. Proiectarea 
cvasiindependenta a masinii fizice respectiv a softului a condus la un “baroc” al 
structurii hardware, caracterizata în final de o eficienta redusa precum si de un grad 
scazut de utilizare a resurselor. Având în vedere necesitatea actuala de satisfacere 
simultana a criteriilor antagoniste de compatibilitate si performanta, se constata 
frecvent o fuziune a conceptelor de CISC si RISC. [1], [2.1], [2.2], [2.3], [2.4.2], 


[2.4.5], [3.1] 


Coerenta a cache -urilor — cerinta ca atunci cand un procesor citeste o data 
sa citeasca ultima valoare (copie) inscrisa a acelei date. Aceasta cerinta pune 


probleme serioase cu deosebire in sistemele multiprocesor. [5.3] 


Exceptie — eveniment care determina întreruperea secventei de program 
executata curent si intrarea într-o rutina de tratare corespunzatoare. Dupa 
executarea acestei rutine se reia programul principal cu executia instructiunii care a 
provocat exceptia (deruta) sau cu executia instructiunii urmatoare celei care a fost 
întrerupta de un eveniment (întrerupere). [2.1], [2.2], [2.4.5.], [3.4], [4] 

- precisa — exceptie care permite structurii pipeline sa fie oprita si - în urma 
executiei rutinei de tratare — programul întrerupt sa fie reluat în conditii 
deterministe. [2.4.5] 

- imprecisa — exceptie care nu permite reluarea activitatii procesului întrerupt 
în conditii complet deterministe, datorita unor caracteristici ale procesarii pipeline. 


[2.4.5] 


Executie speculativa — executia unor instructiuni situate dupa o instructiune 


de salt, înaintea acesteia sau chiar în paralel, prin anumite transformari ale 


programului. [2.4.7], [3.1], [3.7.1], [7.2.1] 


Forwarding — vezi “bypassing”. [2.4.4.2], [3.3], [3.4], [3.9], [4.5], [7.2.1] 


Hazard — situatie care poate sa apara in cadrul procesarii pipeline si care 
determina blocarea fluxului de procesare pentru un anumit numar de cicli. [1], 
[2.1], [2.4.1], [2.4.2], [2.4.4], [244.1], [2.4.4.2], [2.4.4.3], [2.4.7], [3.1], [3.3], 
[3.4], [3.6.3], [3.8.2], [3.10], [3.11], [4], [5.1], [5.2], [5.3], [7.1], [7.2.1], [7.2.2] 

- structural — hazard determinat de conflictele mai multor procese la o 
resursa comuna. [2.4.4], [2.4.4.1], [2.4.4.3], [3.1], [3.2], [3.3], [3.4], [3.6.4], [3.10], 
[4], [4.2.1], [7.2.1] 

- de date — hazard care apare atunci cand exista o dependenta de date intre 2 
instructiuni din structura pipeline. [2.4.4], [2.4.4.2], [2.4.4.3], [2.4.7], [3.1], [3.3], 
[3.6.2], [3.6.3], [3.6.4], [3.7.1], [3.10], [3.11], [4.5], [5.3], [7.1], [7.2.1], [7.2.2] 

- RAW (Read After Write) — hazard de date care apare atunci când o 
instructiune j succesiva unei instructiuni i, citeste o sursa înainte ca instructiunea i 
sa o modifice. [2.4.4.2], [3.2], [3.3], [3.4], [3.6.2], [3.6.4], [3.8.2], [3.9], [3.10], 
[3.11], [5.2], [5.3], [7.2.1], [7.2.2] 

- WAR (Write After Read) — hazard de date care ap are atunci când o 
instructiune j succesiva unei instructiuni i, scrie o destinatie înainte ca aceasta sa fie 
citita pe post e sursa de catre instructiunea i. [2.4.4.2], [3.3], [3.6.2], [3.6.3], 


[3.7.1], [3.8.2], [3.10], [5.2], [7.1], [7.2.1] 


- WAW (Write After Write) — hazard de date care apare atunci cand se 
inverseaza ordinea de scriere a aceleiasi resurse in cazul a 2 instructiuni succesive. 
[2.4.4.2], [3.3], [3.6.2], [3.6.3], [3.7.1], [3.10], [5.2], [7.1], [7.2.1] 

- de ramificatie — hazarduri determinate de calculul intarziat al adresei de 


salt si al directiei de salt in cazul instructiunilor de ramificatie. [2.4.4.3], [2.4.7] 


I.L.P. (Instruction Level Parallelism) — domeniu al stiintei si ingineriei 
calculatoarelor care se ocupa cu determinarea unor metode si tehnici hard — soft în 
vederea exploatarii paralelismului existent la nivelul instructiunilor în cadrul 


microprocesoarelor cu executii multiple si pipeline- izate ale instructiunilor. [1], 


[3.10], [4.5], [7.2.1], [7.2.2] 


Interferenta (salturi) — fenomen ce apare pe parcursul predictiei 
ramificatiilor daca mai multe salturi din program acceseaza aceeasi locatie din 


tabela de predictie. [2.4.4.3], [5.2], [5.3], [6.1], [6.2], [6.3] 


Memorie virtuala (MV) - tehnica de organizare dinamica a memoriei prin 
intermediul careia programele “vad” un spatiu virtual de adresare foarte mare 
(practic nelimitat) si care este mapat in spatiul mult mai redus de memorie fizic 
disponibila. Prin sistemul de MV practic toata memoria principala devine un cache 


între procesor si discul magnetic, reducându-se astfel timpul mediu de acces la 


discul magnetic. MV este un concept esential în sistemele de calcul 


multiprogramate. [2.1], [2.3] 


MMU (Memory Management Unit) — modul functional uzual integrat în 
microprocesor cu rolul de translatare a adresei virtuale emisa de procesor într-o 
adresa fizica de acces la memorie respectiv de asigurare a mecanismelor e control 


Si protectie a accesului la memorie (vezi si memoria virtuala). [2.1], [2.3] 


Pasul unui vector — diferenta numerica dintre adresele de memorie la care se 


afla doua elemente scalare succesive ale vectorului. [3.11] 


Predicare — tehnica de procesare care urmareste executia speculativa a 
instructiunilor si reducerea ramificatiilor de program prin utilizarea instructiunilor 


cu executie conditionata. [2.4.7], [7.2.2] 


Predictor corelat — predictor de ramificatii care se bazeaza în procesul de 
predictie pe lânga “istoria” saltului respectiv si de o informatie de corelatie care 
consta în comportamentul anterior al salturilor precedente saltului curent. [2.4.4.3], 


[6.3] 


Predictia ramificatiilor — procesul de predictie desfasurat pe parcursul fazei 
de aducere a instructiunii a urmatoarelor informatii: daca instructiunea adusa este 
una de ramificatie sau nu, în caz ca e ramificatie daca se face sau nu, iar daca se 
face - adresa destinatie la care se face. Predictia ramificatiilor este foarte necesara 
in procesoarele super — pipeline - izate si superscalare. [1], [2.4.4.3], [3.3], [3.5], 
[3.7.1], [3.8.2], [3.10], [4], [4.1.1], [4.2.1], [4.2.2.1], [4.3], [4.5], [5.1], [5.2], [6], 


[6.1], [6.2], [6.3], [7.1], [7.2.1] 


Prefetch — mecanism de aducere anticipata a instructiunilor desfasurat în 
paralel cu executia unor instructiuni aduse în procesor si memorate într-o coada 
FIFO numita buffer de prefetch. [1], [2.4.4.3], [3.1], [3.3], [3.4], [3.6.4], [3.10], [4], 
[4.1.1], [4.2.1], [4.2.1.1], [4.2.2], [4.2.2.1], [4.3], [4.4], [5.1], [5.2], [5.3], [7.1], 


[7.2.1] 


Procesare (a instructiunii) — totalitatea actiunilor desfasurate de procesor în 
vederea aducerii, decodificarii si executiei unei instructiuni masina. [1], [2.1], 
[2.2], [2.4], [2.4.1], [2.4.2], [2.4.3], [2.4.4], [2.4.4.1], [2.4.4.2], [2.4.4.3], [2.4.5], 
[2.4.7], [3.1], [3.2], [3.3], [3.4], [3.6], [3.6.2], [3.6.3], [3.6.4], [3.7.1], [3.8.1], 
[3.8.2], [3.10], [3.11], [4], [4.1.1], [4.1.2], [4.2.1], [4.2.1.1], [4.2.2], [4.2.2.1], [4.3], 


[4.5], [5.1], [5.2], [5.3], [6.1], [7.1], [7.2.1], [7.2.2] 


- pipeline (de instructiuni) — tehnica de procesare prin care fazele succesive 
aferente instructiunilor succesive sunt suprapuse in timp in vederea obtinerii unui 
paralelism temporal care conduce la o performanta teoretica de o instructiune per 
ciclu. [1], [2], [2.1], [2.4], [2.4.1], [2.4.2], [2.4.3], [2.4.4], [2.4.4.1], [2.4.4.2], 
[2.4.4.3], [3.1], [3.4], [3.8.2], [3.9], [3.10], [3.11], [4], [4.1.1], [4.1.2], [4.2], 
[4.2.1.1], [4.2.2], [4.3], [4.5], [5.2], [6], [6.1], [7.1] 

- vectoriala — procesarea informatiei numerice sub forma de vectori. 
Provocarea esentiala aici consta în elaborarea unor tehnici hard — soft eficiente de 
vectorizare a buclelor de program. [1], [3.11] 

- In Order — executia instructiunilor se face în ordinea scrierii lor în cadrul 
programului. [2.4.4.2], [3.2], [3.3], [3.4], [3.5], [3.6], [3.6.4], [3.7.1], [3.8.1], [5.1], 
[5.2], [5.3], [7.1], [7.2.2] 

- Out of Order — executia instructiunilor se face în afara ordinii lor din 
program, în scopul unei procesari paralele a unor instructiuni independente din 
cadrul programului. [1], [2.4.4.2], [2.4.5], [3.2], [3.3], [3.4], [3.5], [3.6], [3.6.4], 


[3.7.1], [3.10], [7.2.1] 


Procesor — structura digitala complexa, compusa dintr-o unitatea de 
comanda, unitati de executie, registri si magistrale de interconectare, având ca 
principal rol aducerea instructiunilor din memorie, decodificarea si executia 


acestora. [1], [2.1], [2.2], [2.3], [2.4], [2.4.2], [2.4.3], [2.4.4], [2.4.4.1], [2.4.4.2], 


[2.4.4.3], [2.4.5], [2.4.6], [2.4.7], [3.1], [3.2], [3.3], [3.4], [3.5], [3.6], [3.6.2], 
[3.6.3], [3.6.4], [3.7.1], [3.8.1], [3.8.2], [3.9], [3.10], [3.11], [4], [4.1.1], [4.1.2], 
[4.2.1], [4.2.2.1], [4.3], [4.5], [5.1], [5.2], [5.3], [6.1], [6.2], [6.3], [7], [7.1], [7.2.1], 
[7.2.2] 

- scalar — procesor care lanseaza î executie o singura instructiune la un 
moment dat. [1], [2.4.4.3], [3.1], [3.8.2], [3.11], [4], [4.1.2], [6.1], [7.1] 

- MEM (masina cu executii multiple) — care poate lansa în executie mai 
multe instructiuni masina simultan. [1], [2.4.2], [2.4.3], [2.4.4.1], [2.4.4.2], [2.4.5], 
[2.4.6], [3.1], [3.5], [3.6], [3.7], [3.10], [3.11], [4], [4.1.1], [4.1.2], [4.2], [4.2.1], 
[4.2.2], [4.2.2.1], [4.4], [4.5], [5.2], [6.1], [6.2], [7.1], [7.2.1], [7.2.2] 

- superscalar — procesor MEM în care verificarea independentei 
instructiunilor si rutarea acestora spre unitatile de executie multiple se realizeaza 
direct prin hardware. [1], [2.4.4.1], [2.4.6], [3.1], [3.2], [3.2], [3.4], [3.5], [3.6], 
[3.6.2], [3.6.4], [3.7.1], [3.8.1], [3.8.2], [3.9], [3.10], [4], [4.1.1], [4.2.2.1], [4.5], 
[5.1], [5.2], [6.1], [7.1], [7.2.1], [7.2.2] 

- VLIW (Very Long Instruction Word) — procesor MEM care aduce si 
executa mai multe instructiuni RISC primitive si independente simultan. Aceste 


A 


instructiuni primitive sunt “împachetate” într-o asa mmita instructiune multipla de 
catre o componenta a compilatorului numita reorganizator (scheduler). Rutarea 


instructiunilor primitive spre unitatile de executie se face automat functie de pozitia 


pe care o ocupa fiecare in cadrul instructiunii multiple. [1], [2.4.4.3], [2.4.6], [3.1], 
[3.5], [3.6], [3.6.2], [3.7], [3.7.1], [3.9], [3.10], [4], [7.1], [7.2.1], [7.2.2] 

- EPIC (Explicitly Parallel Instruction Computing) — concept introdus de 
compania Intel in cadrul arhitecturii sale IA-64, bazat pe rafinarea conceptului de 
procesare VLIW în special în sensul mascarii unor caracteristici hardware (latente 
instructiuni, tipuri unitati de executie, etc.) pentru reorganizatorul de cod. Filosofia 
EPIC are la baza executia conditionata a instructiunilor în scopul eliminarii 
instructiunilor de salt (predicare) si respectiv executia speculativa a instructiunilor 
(înainte ca si conditia de ramificare sa fie evaluata), ambele cu repercursiuni 
pozitive asupra eficientei structurii de procesare. [3.1] 

- TTA (Transport Triggered Architectures) — expresie limita a arhitecturii 
RISC, desemneaza un procesor cu o singura instructiune (MOVE), bazata in esenta 
pe separarea transportului datelor de procesarea (prelucrarea) lor efectiva. In cadrul 
TTA declansarea procesarii efective se face printr-un transport in registrul trigger 
aferent unitatii de executie. Geneza acestui concept provine de la Universitatea din 


Delft, Olanda. [1], [3.9] 


Rata de hit — raportul dintre numarul acceselor la memorie cu succes în 
cache respectiv numarul total al acceselor la memorie din partea procesorului. [4], 


[4.1.1], [5.1], [5.2] 


Rata de miss — complementara ratei de hit. [4], [4.3], [4.4], [5.2], [5.3] 


Rata medie de procesare (Average Issue Rate) — metrica globala de 
evaluare a performantelor reprezentând numarul total de instructiuni executate 
raportat la numarul total al impulsurilor de tact necesare executiei acestor 
instructiuni, exprimata în instructiuni / tact. [4], [4.1.1], [4.2.1], [4.2.2], [4.5], [5.1], 


[5.2], [6.1] 


Retea neuronala (RN) — structura alcatuita prin interconectarea unor neuroni 
artificiali prin legaturi ponderate, având capacitati de învatare, generalizare, sinteza 
si autoorganizare. RN au aplicatii interesante în recunoasterea formelor precum si 
în alte probleme e inteligenta artificiala. Autorul le -a utilizat aici pentru prima data 


în problematica predictiei salturilor. [6.3] 


RISC (Reduced Instruction Set Computing) — arhitectura optimizata de 
procesor bazata pe pragmatism si eficienta. În opinia autorului, esenta novatoare a 
acestui concept consta în optimizarea hardware — software bazata pe statistici ale 
programelor si simulari laborioase si având ca scop final procesarea eficienta a 
unor aplicatii reprezentative (benchmark — uri) scrise în limbaje evoluate. Dintre 
caracteristicile principale ale arhitecturilor RISC se amintesc: set relativ redus de 


instructiuni masina, model ortogonal de programare, instructiuni codificate pe un 


singur cuvant, doar instructiunile LOAD si STORE acceseaza memoria de date, 
procesare pipeline a instructiunilor masina, etc. Conceptul isi are geneza la 
începuturile anilor ‘80, din cercetari efectuate atât în medii industriale (IBM) cât si 
academice (Universitatile Berkeley si Stanford, S.U.A.). [1], [2.1], [2.2], [2.3], 
[2.4], [2.4.2], [2.4.3], [2.4.4], [2.4.4.1], [2.4.4.2], [2.4.4.3], [2.4.5], [3.1], [3.8.1], 


[3.9], [3.10], [3.11], [4], [4.1.2], [4.2], [4.3], [4.5], [5.2], [5.3], [6.1], [7.1] 


Scoreboarding — tehnica de detectie a hazardurilor de date într-o structura 
pipeline de procesare bazata pe asocierea unui bit de scor fiecarui registru, cu 
semnificatia registru utilizabil / neutilizabil. În cazul detectiei unui hazard de date 


structura pipeline de procesare se opreste. [2.4.4.2], [3.1] 


Scheduler (Reorganizator de program) — program care în general 
reprezinta o componenta a compilatorului, destinat reorganizarii programului 
obiect în vederea procesarii sale într-un timp cât mai scurt pe o anumita masina 
hardware. Este o componenta software esentiala a oricarei arhitecturi paralele, 
constituind de altfel principala provocare a arhitecturilor paralelele. 1], [2.1], 
[2.4.4.2], [2.4.4.3], [2.4.7], [3.6.2], [3.6.3], [3.6.4], [3.7], [3.10], [4], [5.2], [7], 


[7.1], [7.2.1], [7.2.2] 


Statie de rezervare (SR) — structura de date implementata în cadrul 
procesoarelor superscalare cu scopul facilizarii procesarii Out of Order a 
instructiunilor. Lansarea în executie a unei instructiuni rezidenta în bufferul de 
prefetch înseamna mutarea acesteia în SR aferenta. De aici, instructiunea se 
lanseaza efectiv în executie atunci când toti operanzii sai sursa sunt disponibili. SR 
efectueaza o redenumire dinamica a registrilor în vederea eliminarii hazardurilor de 
date tip WAR si WAW. De asemenea aceste statii faciliteaza executia prin captarea 
agresiva a unor rezultate asteptate de catre instructiunile aflate în stare asteptare. 


[3.3], [3.4], [3.10], [4.5] 


Trace — un “fisier” care contine instructiunile unui program, contigue din 
punct de vedere al executiei lor si scrise în locatii succesive ale fisierului. 
Instructiunile dintr-un trace au atasate toate informatiile rezultate în urma executiei 
lor propriu zise (PC, adrese acces memorie date, adrese destinatie salt, etc.). [1], 
[2.4.4.3], [3.7], [3.7.1], [3.10], [4.1.1], [4.3], [5.1], [5.2], [5.3], [6.2], [6.3], [7.1], 
[7.2.1], [7.2.2] 

- Trace procesor — un procesor MEM care exploateaza reutilizarea 
secventelor dinamice de instructiuni anterior executate si memorate într-o memorie 
speciala numita trace cache. Se mareste astfel atât rata de aducere a instructiunilor 
cât si rata de executie a acestora, fata de paradigma superscalara clasica (generatia 


a III-a de microprocesoare d.p.d.v. arhitectural). [3.10] 


Unitate de comanda (control) — dispozitiv numeric care genereaza 
secventiat in timp toate impulsurile de comanda necesare în structura hardware 
pentru aducerea, decodificarea si executia instructiunilor masina. [2.1], [2.2] 

- cablata — U.C. implementata sub forma unui automat secvential (sincron) 
complex. Proiectarea acestuia se face pe baza descrierii în limbaj specializate 
(HDL - Hardware Description Languages) a fiecarei faze aferente fiecarei 
instructiuni la nivelul de “transfer registru”. U.C. cablate sunt specifice 
procesoarelor în filosofie RISC fiind principial rapide. [2.1] 

- microprogramata — U.C. care genereaza comenzile pe baza unui asa numit 
microprogram de emulare a instructiunilor, stocat într-o memorie de 
microprogram. Acest  microprogram contine  microrutine  înlantuite in 
corespondenta cu fazele de executie ale fiecarei instructiuni (aducere, decodificare, 
executie, etc.). Comenzile hardware se genereaza prin decodificarea câmpurilor 
microinstructiunilor. Microprogramarea este mai flexibila decât proiectarea 
cablata, permitând o dezvoltarea facila a setului de instructiuni de la o versiune la 
alta. Uzual, o UC microprogramata este mai lenta decât una cablata prin faptul ca, 
principial, fiecare microinstructiune se proceseaza în 2 cicli: aducere si executie 
(generare comenzi). Aceasta metoda de proiectare a fost introdusa în 1951 printr- 


un articol al lui Maurice Wilkes (Universitatea din Cambrige, Marea Britanie) si 


adoptata pe plan comercial de catre IBM abia la începuturile anilor “60. A fost si 


mai este inca utilizata pe modelele de procesoare CISC. [3.7.1], [2.4.4.2] 
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